From dan.track at gmail.com  Fri Jul  1 08:11:14 2005
From: dan.track at gmail.com (Dan Track)
Date: Fri, 1 Jul 2005 09:11:14 +0100
Subject: Has anyone got rhel3 running under fc4 as a domu
In-Reply-To: <20050630160155.GP14660@redhat.com>
References: <9d5ddd1f05063007381ffee524@mail.gmail.com>
	<1120142887.10079.6.camel@orion>
	<9d5ddd1f0506300801312c2d04@mail.gmail.com>
	<20050630160155.GP14660@redhat.com>
Message-ID: <9d5ddd1f05070101117df97c73@mail.gmail.com>

On 6/30/05, Daniel Veillard <veillard at redhat.com> wrote:
> On Thu, Jun 30, 2005 at 04:01:46PM +0100, Dan Track wrote:
> > Hi
> >
> > Thanks for the reply.
> >
> > I've been banging my head againstg this for two days now.
> >
> > I'm using FC4 kernel: 2.6.11-1.1369_FC4xen0
> >
> > rhel3 is the standard kernel available on redhat. I had all this
> > working under fc4_test1 without any problems. When FC4 came out I
> > couldn't get it to work. I've tried all of the MAKEDEV commands but it
> > still doesn't work.
> >
> > The strange thing is that rhel4 does work under FC4 as a domU.
> >
> > Any ideas. I'm really desparate for some.
> 
>   RHEL3 uses a 2.4 kernel. You're trying to boot it up with a 2.6 kernel,
> so yeah having troubles is not surprizing. On the other hand RHEL4/FC4
> use 2.6, the gap between expected kernel and the one provided by Xen is
> small in comparison, and that just works.
> 
> Daniel
> 
> --
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
> 


Hi

Many Thanks for your reply.

I'm kind of new to this area, so I'm trying to get my head round a few things.

I think the issue lies in me needing a initrd, I need to supply that
with the xenu to boot the rhel 3 distro. I ran the following:

touch /lib/modules/2.6.11-1.1369_FC4xenU/modules.dep
mkinitrd /boot/initrd-2.6.11-1.1369_FC4xenU.img 2.6.11-1.1369_FC4xenU

I then put this ramdisk in the rhel-3-es xen file

kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU"
ramdisk = "/boot/initrd-2.6.11-1.1369_FC4xenU.img"
memory = 260
name = "rhel-3-es"
nics = 1
disk = ['phy:hda3,sda1,w']
root = "/dev/sda1 ro"

But when booting up rhel-3-es doesn't, it gives the following message:

 xm create -c rhel-3-es
Using config file "/etc/xen/rhel-3-es".
Started domain rhel-3-es, console on port 9601
************ REMOTE CONSOLE: CTRL-] TO QUIT ********
Linux version 2.6.11-1.1369_FC4xenU
(bhcompile at decompose.build.redhat.com) (gcc version 4.0.0 20050525
(Red Hat 4.0.0-9)) #1 SMP Thu Jun 2 23:33:51 EDT 2005
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000010400000 (usable)
260MB LOWMEM available.
Using x86 segment limits to approximate NX protection
DMI not present.
IRQ lockup detection disabled
Allocating PCI resources starting at 10400000 (gap: 10400000:efc00000)
Built 1 zonelists
Kernel command line:  root=/dev/sda1 ro
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Xen reported: 598.075 MHz processor.
Using tsc for high-res timesource
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 257024k/266240k available (1785k kernel code, 8956k reserved,
506k data, 156k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 1024K
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... disabled
CPU0: Intel(R) Pentium(R) M processor 1600MHz stepping 05
per-CPU timeslice cutoff: 2925.79 usecs.
task migration cache decay timeout: 3 msecs.
SMP motherboard not detected.
smpboot_clear_io_apic_irqs
Brought up 1 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 2033k freed
softlockup thread 0 started up.
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.
Grant table initialized
audit: initializing netlink socket (disabled)
audit(1120205224.359:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 42BD35A990375F72
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Xen virtual console successfully installed as tty1
Event-channel device installed.
Blkif frontend is using grant tables.
xen_blk: Initialising virtual block device driver
xen_net: Initialising virtual ethernet driver.
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 16384 (order: 5, 196608 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 156k freed
Red Hat nash version 4.2.15 starting
Mounted /proc filesystem
Mounting sysfs
Creating /dev
Starting udev
echo: cannot open /proc/sys/kernel/hotplug for write: 2
Creating root device
Mounting root filesystem
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Switching to new root
unmounting old /proc
unmounting old /sys

And then it just hangs. I'm pretty sure its to do with using a 2.6
kernel image having troubles with booting a 2.4 kernel. Which is
exactly what you said Daniel. The problem is I don't know how to make
an initrd that will work under rhel-3-es or any other 2.4 kernel
distro. I would be really grateful if someone could show me how to do
this.

I know this may be basic for you guys on the list, but I'm really
stumped for ideas.

I appreciate your help.

Many Thanks
Dan



From db-fedora at 3di.it  Fri Jul  1 08:55:58 2005
From: db-fedora at 3di.it (Davide Bolcioni)
Date: Fri, 01 Jul 2005 10:55:58 +0200
Subject: Wish list for FC5 - add Nvu
Message-ID: <42C5051E.6090402@3di.it>

Greetings,
my suggestion for FC5 is to include Nvu 1.0 alongside Firefox and 
Thunderbird, thereby almost replicating the functionality of the Mozilla 
suite.

Thank you for your consideration,
Davide Bolcioni
-- 
There is no place like /home.



From tarjei.knapstad at predichem.com  Fri Jul  1 09:31:38 2005
From: tarjei.knapstad at predichem.com (Tarjei Knapstad)
Date: Fri, 01 Jul 2005 11:31:38 +0200
Subject: Wish list for FC5 - add Nvu
In-Reply-To: <42C5051E.6090402@3di.it>
References: <42C5051E.6090402@3di.it>
Message-ID: <1120210298.17450.8.camel@tarjei.predichem.nett>

On Fri, 2005-07-01 at 10:55, Davide Bolcioni wrote:
> Greetings,
> my suggestion for FC5 is to include Nvu 1.0 alongside Firefox and 
> Thunderbird, thereby almost replicating the functionality of the Mozilla 
> suite.
> 

Hi Davide,

I believe the current plan is to reduce the size of Core (down from 4 to
maybe just 1 or 2 discs) and at the same time heavily expand Extras to
make it more an integral part of the Fedora distro. (correct me if I'm
wrong!) I'm all for this as long as Extras becomes a bit more mature
than it has been and we can spin CD's/DVD's of Extras for people to
download/buy too.

In any case, the path for getting a package into Core goes through
Extras so the package has to get in Extras first and get some approval
before it can possibly be moved to Core. More info on getting involved
with Extras here: 

http://fedoraproject.org/wiki/Extras

Remember that when you suggest something in the open source community
you've halfway volunteered to do it yourself ;)

Regards,
--
Tarjei



From ovidiu at linux360.ro  Fri Jul  1 09:39:45 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Fri, 01 Jul 2005 12:39:45 +0300
Subject: Fedora Core 5 Idea
In-Reply-To: <42C44549.8060706@redhat.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com>
Message-ID: <42C50F61.2090806@linux360.ro>

Rahul Sundaram wrote:

> If you like it, you can use it. It still exists. Themes are a subjective 
> taste and clear looks is the default now for GNOME.

As if BlueCurve were the default theme for GNOME in the RH8 -> FC3 era. 
Your argument doesn't stand. And yes, I like BlueCurve more than 
Clearlooks too.

> Already in the wish list. http://fedoraproject.org/wiki/Wishlist. 
> Personally I like the idea of doing something similar to the early GDM 
> login and new init script to make bootup faster to apply to shutdown too 
> so that it not slow enough to add graphics to make the wait look better

And that won't work with the NVIDIA binary drivers either. I think this, 
as well as rhgb, are a waste of developers' time.

-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/65bb4497/attachment.bin>

From fedora at camperquake.de  Fri Jul  1 09:44:22 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 1 Jul 2005 11:44:22 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <42C50F61.2090806@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
Message-ID: <20050701114422.0de7ca3e@nausicaa.camperquake.de>

Hi.

Ovidiu Lixandru <ovidiu at linux360.ro> wrote:

> And yes, I like BlueCurve more than Clearlooks too.

And I happen to like clearlooks more. So what?

> And that won't work with the NVIDIA binary drivers either.

Being compatible with nvidias drivers is not exactly a stated goal
of FC.



From sundaram at redhat.com  Fri Jul  1 10:19:18 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 01 Jul 2005 15:49:18 +0530
Subject: Fedora Core 5 Idea
In-Reply-To: <42C50F61.2090806@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>
Message-ID: <42C518A6.3000000@redhat.com>

Ovidiu Lixandru wrote:

> Rahul Sundaram wrote:
>
>> If you like it, you can use it. It still exists. Themes are a 
>> subjective taste and clear looks is the default now for GNOME.
>
>
> As if BlueCurve were the default theme for GNOME in the RH8 -> FC3 
> era. Your argument doesn't stand. And yes, I like BlueCurve more than 
> Clearlooks too.

 Just because something is the default isnt going to change your 
personal opinion on it. So instead of convincing people to adopt your 
choices as the default it would be better to just switch the theme over 
after the installation or during kickstart. If you do have rational 
arguments about other set of preferences in various applications, 
developers are more likely to hear you because it generally is much more 
applicable to a wider set of people. I am pretty sure that are dozens of 
other themes which some of the users like which isnt being shipped in 
Fedora Core at all.  You should use the theme sites like 
http://art.gnome.org or http://kde-look.org.  Applications that grab 
such themes from various sites and make the end user experience in 
changing the themes from a wider variety more transparent and easier 
would be a good thing to do. Thats where I would like to see the effort 
go towards in extras or even in core

regards
Rahul




From ovidiu at linux360.ro  Fri Jul  1 10:19:43 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Fri, 01 Jul 2005 13:19:43 +0300
Subject: Fedora Core 5 Idea
In-Reply-To: <20050701114422.0de7ca3e@nausicaa.camperquake.de>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>
	<20050701114422.0de7ca3e@nausicaa.camperquake.de>
Message-ID: <42C518BF.2030802@linux360.ro>

Ralf Ertzinger wrote:

> And I happen to like clearlooks more. So what?

"As if BlueCurve were the default theme for GNOME in the RH8 -> FC3 era. 
Your argument doesn't stand."
You forgot this. My preference was not used as an argument.

> Being compatible with nvidias drivers is not exactly a stated goal
> of FC.

I didn't say that. I said FC should use its efforts better for the 
benefit of its users. If you develop a program which the majority of the 
desktop users won't use because of *official* driver incompatibility, 
you definitely have some goal issues.

-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/7ca3893c/attachment.bin>

From sundaram at redhat.com  Fri Jul  1 10:23:56 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 01 Jul 2005 15:53:56 +0530
Subject: Fedora Core 5 Idea
In-Reply-To: <42C50F61.2090806@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>
Message-ID: <42C519BC.6@redhat.com>

Hi

>> Already in the wish list. http://fedoraproject.org/wiki/Wishlist. 
>> Personally I like the idea of doing something similar to the early 
>> GDM login and new init script to make bootup faster to apply to 
>> shutdown too so that it not slow enough to add graphics to make the 
>> wait look better
>
>
> And that won't work with the NVIDIA binary drivers either. I think 
> this, as well as rhgb, are a waste of developers' time.
>
I am not sure you read me correctly. Work in going towards removing RHGB 
and making the boot process faster. In a similar fashion if the shutdown 
is also made faster, the need for graphics there is much less. So 
without the graphics involved the Nvidia drivers arent going to come 
into play.

regards
Rahul



From ovidiu at linux360.ro  Fri Jul  1 10:36:42 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Fri, 01 Jul 2005 13:36:42 +0300
Subject: Fedora Core 5 Idea
In-Reply-To: <42C518A6.3000000@redhat.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>	<42C50F61.2090806@linux360.ro>
	<42C518A6.3000000@redhat.com>
Message-ID: <42C51CBA.9010507@linux360.ro>

Rahul Sundaram wrote:

> Just because something is the default isnt going to change your personal 
> opinion on it. So instead of convincing people to adopt your choices as 
> the default it would be better to just switch the theme over after the 
> installation or during kickstart. If you do have rational arguments 
> about other set of preferences in various applications, developers are 
> more likely to hear you because it generally is much more applicable to 
> a wider set of people. I am pretty sure that are dozens of other themes 
> which some of the users like which isnt being shipped in Fedora Core at 
> all.  You should use the theme sites like http://art.gnome.org or 
> http://kde-look.org.  Applications that grab such themes from various 
> sites and make the end user experience in changing the themes from a 
> wider variety more transparent and easier would be a good thing to do. 
> Thats where I would like to see the effort go towards in extras or even 
> in core

You're missing the point. I said BlueCurve was chosen as a default for 
RH8 through FC3 for other reasons, because BlueCurve has never been the 
default theme in official GNOME releases.
As I said some time ago, Fedora Core is losing parts of its graphical 
identity. The desktop now starts by default with a stock GNOME theme 
which does not include a GTK1 theme, the login theme and the wallpaper 
are pretty ugly and quite unprofessional compared to the RHEL ones.
I'm a bit upset about this because I'm a long time RH and FC user and 
I've recommended and installed the distro to a lot of regular users. The 
interface is the first contact they make with the distro and lately I've 
begun considering some other distros for their default interfaces. The 
default desktop interface is not an issue for me, it is however for the 
people I recommend FC to.

-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/659a269d/attachment.bin>

From dan.track at gmail.com  Fri Jul  1 10:37:14 2005
From: dan.track at gmail.com (Dan Track)
Date: Fri, 1 Jul 2005 11:37:14 +0100
Subject: xen, how to boot a 2.4 kernel distro in FC4
Message-ID: <9d5ddd1f05070103372fbd03f0@mail.gmail.com>

Hi

Can someone please help to find a way, while also getting an
understanding as to how to boot a 2.4 kernel distro, in my case rhel
3, as domU under the 2.6 kernel dom0 from FC4.

I'm having problems. Basically I initially though that running a Xen
kernel would allow me to boot any os as a domU no matter what their
kernel was, but I think I have been mistaken with this. I am running
into problem while booting this.

I would really appreciate any help provided. 

Many Thanks
Dan



From ovidiu at linux360.ro  Fri Jul  1 10:39:03 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Fri, 01 Jul 2005 13:39:03 +0300
Subject: Fedora Core 5 Idea
In-Reply-To: <42C519BC.6@redhat.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>	<42C50F61.2090806@linux360.ro>
	<42C519BC.6@redhat.com>
Message-ID: <42C51D47.3010206@linux360.ro>

Rahul Sundaram wrote:

> I am not sure you read me correctly. Work in going towards removing RHGB 
> and making the boot process faster. In a similar fashion if the shutdown 
> is also made faster, the need for graphics there is much less. So 
> without the graphics involved the Nvidia drivers arent going to come 
> into play.

I got you loud and clear. I should've snipped the last part of the 
quote, I was referring just to the entry in the Wishlist.

-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/6b8728f6/attachment.bin>

From caillon at redhat.com  Fri Jul  1 10:41:47 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 01 Jul 2005 06:41:47 -0400
Subject: Wish list for FC5 - add Nvu
In-Reply-To: <1120210298.17450.8.camel@tarjei.predichem.nett>
References: <42C5051E.6090402@3di.it>
	<1120210298.17450.8.camel@tarjei.predichem.nett>
Message-ID: <42C51DEB.3070906@redhat.com>

On 07/01/2005 05:31 AM, Tarjei Knapstad wrote:
> On Fri, 2005-07-01 at 10:55, Davide Bolcioni wrote:
> 
>>Greetings,
>>my suggestion for FC5 is to include Nvu 1.0 alongside Firefox and 
>>Thunderbird, thereby almost replicating the functionality of the Mozilla 
>>suite.
>>
> 
> 
> Hi Davide,
> 
> I believe the current plan is to reduce the size of Core (down from 4 to
> maybe just 1 or 2 discs) and at the same time heavily expand Extras to
> make it more an integral part of the Fedora distro. (correct me if I'm
> wrong!) I'm all for this as long as Extras becomes a bit more mature
> than it has been and we can spin CD's/DVD's of Extras for people to
> download/buy too.
> 
> In any case, the path for getting a package into Core goes through
> Extras so the package has to get in Extras first and get some approval
> before it can possibly be moved to Core. More info on getting involved
> with Extras here: 


I've been meaning to get this packaged up for Extras for some time now, 
but haven't actually been able to get around to it.  If someone wants to 
help out, that would be appreciated.  It would pretty much need to build 
with the same options and patchset (more or less) that we do for the 
thunderbird and firefox builds.  Since Nvu is not based off the exact 
same branch, that proves to be slightly more difficult.  Anyway, this 
discussion belongs on fedora-extras-list, not here.



From caillon at redhat.com  Fri Jul  1 10:48:12 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 01 Jul 2005 06:48:12 -0400
Subject: Fedora Core 5 Idea
In-Reply-To: <42C51CBA.9010507@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>	<42C50F61.2090806@linux360.ro>	<42C518A6.3000000@redhat.com>
	<42C51CBA.9010507@linux360.ro>
Message-ID: <42C51F6C.9000701@redhat.com>

On 07/01/2005 06:36 AM, Ovidiu Lixandru wrote:
> Rahul Sundaram wrote:
> 
>> Just because something is the default isnt going to change your 
>> personal opinion on it. So instead of convincing people to adopt your 
>> choices as the default it would be better to just switch the theme 
>> over after the installation or during kickstart. If you do have 
>> rational arguments about other set of preferences in various 
>> applications, developers are more likely to hear you because it 
>> generally is much more applicable to a wider set of people. I am 
>> pretty sure that are dozens of other themes which some of the users 
>> like which isnt being shipped in Fedora Core at all.  You should use 
>> the theme sites like http://art.gnome.org or http://kde-look.org.  
>> Applications that grab such themes from various sites and make the end 
>> user experience in changing the themes from a wider variety more 
>> transparent and easier would be a good thing to do. Thats where I 
>> would like to see the effort go towards in extras or even in core
> 
> 
> You're missing the point. I said BlueCurve was chosen as a default for 
> RH8 through FC3 for other reasons, because BlueCurve has never been the 
> default theme in official GNOME releases.

ClearLooks is being considered for the same reasons Bluecurve has been 
around, plus others.  See 
http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00453.html



From sundaram at redhat.com  Fri Jul  1 10:48:09 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 01 Jul 2005 16:18:09 +0530
Subject: Fedora Core 5 Idea
In-Reply-To: <42C51CBA.9010507@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>	<42C50F61.2090806@linux360.ro>	<42C518A6.3000000@redhat.com>
	<42C51CBA.9010507@linux360.ro>
Message-ID: <42C51F69.70707@redhat.com>

Ovidiu Lixandru wrote:

> Rahul Sundaram wrote:
>
>> Just because something is the default isnt going to change your 
>> personal opinion on it. So instead of convincing people to adopt your 
>> choices as the default it would be better to just switch the theme 
>> over after the installation or during kickstart. If you do have 
>> rational arguments about other set of preferences in various 
>> applications, developers are more likely to hear you because it 
>> generally is much more applicable to a wider set of people. I am 
>> pretty sure that are dozens of other themes which some of the users 
>> like which isnt being shipped in Fedora Core at all.  You should use 
>> the theme sites like http://art.gnome.org or http://kde-look.org.  
>> Applications that grab such themes from various sites and make the 
>> end user experience in changing the themes from a wider variety more 
>> transparent and easier would be a good thing to do. Thats where I 
>> would like to see the effort go towards in extras or even in core
>
>
> You're missing the point. I said BlueCurve was chosen as a default for 
> RH8 through FC3 for other reasons, because BlueCurve has never been 
> the default theme in official GNOME releases.

Red Hat Linux had a development methodology that is different from 
Fedora. Clear looks itself is based on the BlueCurve engine and with it 
being a potential candidate for the next GNOME default theme, it makes 
more sense to flow along with the upstream thing which is an explicit 
Fedora design goal.

> As I said some time ago, Fedora Core is losing parts of its graphical 
> identity. The desktop now starts by default with a stock GNOME theme 
> which does not include a GTK1 theme, the login theme and the wallpaper 
> are pretty ugly and quite unprofessional compared to the RHEL ones.

Again, You should get into the fedora-marketing list and read the 
discussions there and participate if you have good design skills or even 
ideas on how to go about making Fedora look attractive and better. It 
seems you would rather choose your distribution based on the theme and 
wallpapers rather than switching it over to what fit your tastes better. 
I am pretty sure any given theme isnt going to please everyone

regards
Rahul



From aportal at univ-montp2.fr  Fri Jul  1 10:59:11 2005
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Fri, 1 Jul 2005 12:59:11 +0200
Subject: LDP man-pages
Message-ID: <200507011259.14645.aportal@univ-montp2.fr>

Hi,

I'm really surprised to see that the man-pages package in FC4 is the same 
release than FC3, i.e. 1.67.

Is there any reason for not providing the latest release avaliable?

Yours sincerely.
-- 
Alain PORTAL -- Service Commun de Microscopie ?lectronique
Universit? de Montpellier II -- Case Courrier 087
Place Eug?ne Bataillon -- 34095 Montpellier Cedex 05
T?l. : 04 67 14 37 35 -- Fax. : 04 67 14 37 37

NO WORD ATTACHMENTS: http://www.gnu.org/philosophy/no-word-attachments.fr.html
http://www.giromini.org/usenet-fr/repondre.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/5f2f0def/attachment.sig>

From rms at 1407.org  Fri Jul  1 11:15:47 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 01 Jul 2005 12:15:47 +0100
Subject: Fedora Core 5 Idea
In-Reply-To: <42C518BF.2030802@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114422.0de7ca3e@nausicaa.camperquake.de>
	<42C518BF.2030802@linux360.ro>
Message-ID: <1120216547.2772.40.camel@roque>

On Fri, 2005-07-01 at 13:19 +0300, Ovidiu Lixandru wrote:
> Ralf Ertzinger wrote:
> > Being compatible with nvidias drivers is not exactly a stated goal
> > of FC.
> 
> I didn't say that. I said FC should use its efforts better for the 
> benefit of its users. If you develop a program which the majority of the 
> desktop users won't use because of *official* driver incompatibility, 
> you definitely have some goal issues.

Actually, the official position should be to recommend users to avoid
buying such incompatible hardware, since it's support is minimal.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/ecfc1540/attachment.sig>

From bob.deblier at telenet.be  Fri Jul  1 11:18:21 2005
From: bob.deblier at telenet.be (Bob Deblier)
Date: Fri, 01 Jul 2005 13:18:21 +0200
Subject: xen, how to boot a 2.4 kernel distro in FC4
In-Reply-To: <9d5ddd1f05070103372fbd03f0@mail.gmail.com>
References: <9d5ddd1f05070103372fbd03f0@mail.gmail.com>
Message-ID: <1120216702.3519.21.camel@orion>

On Fri, 2005-07-01 at 11:37 +0100, Dan Track wrote:
> Hi
> 
> Can someone please help to find a way, while also getting an
> understanding as to how to boot a 2.4 kernel distro, in my case rhel
> 3, as domU under the 2.6 kernel dom0 from FC4.
> 
> I'm having problems. Basically I initially though that running a Xen
> kernel would allow me to boot any os as a domU no matter what their
> kernel was, but I think I have been mistaken with this. I am running
> into problem while booting this.
> 
> I would really appreciate any help provided. 

As I've mentioned before: the guest OS, i.e. the one running as a domU,
also needs a specially compiled kernel. See
http://wiki.xensource.com/xenwiki/XenFaq#head-bb579ddda3999d87064a36b7d847fad8e39440ae

This is because Xen is a paravirtualizer instead of a full virtualizer,
like VMware.

Wouldn't it be better to ask questions like this on the xen-users list?
The lack of responses here seems to indicate a general lack of knowledge
in this topic...

Sincerely,

Bob Deblier




From dragoran at feuerpokemon.de  Fri Jul  1 11:29:51 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Fri, 01 Jul 2005 13:29:51 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <1120216547.2772.40.camel@roque>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>	<20050701114422.0de7ca3e@nausicaa.camperquake.de>	<42C518BF.2030802@linux360.ro>
	<1120216547.2772.40.camel@roque>
Message-ID: <42C5292F.3040509@feuerpokemon.de>

Rui Miguel Seabra wrote:

>On Fri, 2005-07-01 at 13:19 +0300, Ovidiu Lixandru wrote:
>  
>
>>Ralf Ertzinger wrote:
>>    
>>
>>>Being compatible with nvidias drivers is not exactly a stated goal
>>>of FC.
>>>      
>>>
>>I didn't say that. I said FC should use its efforts better for the 
>>benefit of its users. If you develop a program which the majority of the 
>>desktop users won't use because of *official* driver incompatibility, 
>>you definitely have some goal issues.
>>    
>>
>
>Actually, the official position should be to recommend users to avoid
>buying such incompatible hardware, since it's support is minimal.
>
>Rui
>
>  
>
the problem is that the don't have any other choice ....
recommend user to buy older or slower hardware isn't the right way..



From buildsys at redhat.com  Fri Jul  1 11:33:23 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 1 Jul 2005 07:33:23 -0400
Subject: rawhide report: 20050701 changes
Message-ID: <200507011133.j61BXNmx018571@porkchop.devel.redhat.com>

New package asm
	A code manipulation tool to implement adaptable systems

New package fractal
	A general software composition framework


 
Updated Packages:

SysVinit-2.85-40
----------------
* Thu Jun 30 2005 Bill Nottingham <notting at redhat.com> - 2.85-40
- pidof: fix the fix for #85796, which broke the fix for #138788

gstreamer-plugins-0.8.9-2
-------------------------
* Thu Jun 30 2005 John (J5) Palmieri <johnp at redhat.com> - 0.8.9-2
- Backport patch from cvs to fix soundjuicer 
- disable the cairo plugin as it uses the old API

kdeartwork-3.4.1-2
------------------
* Thu Jun 30 2005 Than Ngo <than at redhat.com> 3.4.1-2 
- configure script does not look the right xscreensaver dirs
  apply patch to fix this problem, #161312, thanks to Rex Dieter

kdevelop-9:3.2.1-2
------------------
* Thu Jun 30 2005 Than Ngo <than at redhat.com> 9:3.2.1-2
- apply patch to fix undefined symbol issue #162146

linuxdoc-tools-0.9.21-6
-----------------------
* Thu Jun 30 2005 Tim Waugh <twaugh at redhat.com> 0.9.21-6
- Finnish translation (bug #162151).

rhpl-0.168-1
------------
* Thu Jun 30 2005 Chris Lumens <clumens at redhat.com> 0.168-1
- Use Python's gzip module instead of our own gzread for .mo files.

tcl-8.4.11-1
------------
* Fri Jul 01 2005 Jens Petersen <petersen at redhat.com> - 8.4.11-1
- update to latest stable release
  - update tcl-8.4-autoconf.patch
- buildrequire sed and use it instead of perl for editting tclConfig.sh

* Wed Mar 09 2005 Jens Petersen <petersen at redhat.com> - 8.4.9-3
- rebuild with gcc 4

* Tue Dec 14 2004 Jens Petersen <petersen at redhat.com> - 8.4.9-2
- move tclConfig.sh into -devel (Axel Thimm, 142724)

tk-8.4.11-1
-----------
* Fri Jul 01 2005 Jens Petersen <petersen at redhat.com> - 8.4.11-1
- update to 8.4.11 stable release
  - update tk-8.4.4-lib-perm.patch

xorg-x11-6.8.2-40
-----------------
* Thu Jun 30 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-40
- Added xorg-x11-6.8.2-xkb-dutch-keyboard-layout-fixes.patch as a proposed
  fix for Dutch keyboard layout issue (#135233)

* Thu Jun 23 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-39
- Updated xdm.pamd to work with new audit system. (#159332)
- Made copy of xdm.pamd named "xdm-pre-audit-system.pamd" for FC3/FC4 builds.
- Added xorg-x11-xdm "Requires: pam >= 0.77-66.8" for RHEL-4 builds, and
  "Requires: pam >= 0.79-10" for FC5 builds.  The audit functionality is
  disabled for FC3/FC4 builds.
- Added new build target macro "build_fc5" and updated spec file to use
  it where appropriate.

Broken deps for ia64
----------------------------------------------------------
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	rgmanager - 1.9.31-3.ia64 requires ccs
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta












Broken deps for ppc64
----------------------------------------------------------
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	firstboot - 1.3.42-1.noarch requires system-config-display
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	rhpl - 0.168-1.ppc64 requires pyxf86config >= 0:0.3.2
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet



Broken deps for s390x
----------------------------------------------------------
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections



Broken deps for s390
----------------------------------------------------------
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl





From rms at 1407.org  Fri Jul  1 11:39:34 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 01 Jul 2005 12:39:34 +0100
Subject: Fedora Core 5 Idea
In-Reply-To: <42C5292F.3040509@feuerpokemon.de>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114422.0de7ca3e@nausicaa.camperquake.de>
	<42C518BF.2030802@linux360.ro> <1120216547.2772.40.camel@roque>
	<42C5292F.3040509@feuerpokemon.de>
Message-ID: <1120217974.2772.47.camel@roque>

On Fri, 2005-07-01 at 13:29 +0200, dragoran wrote:
> Rui Miguel Seabra wrote:
> the problem is that the don't have any other choice ....
> recommend user to buy older or slower hardware isn't the right way..

Being held hostage to questionable market moves isn't the right way
either.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/82efc886/attachment.sig>

From fedora at camperquake.de  Fri Jul  1 11:41:23 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 1 Jul 2005 13:41:23 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <42C51CBA.9010507@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<42C518A6.3000000@redhat.com> <42C51CBA.9010507@linux360.ro>
Message-ID: <20050701134123.7812dc03@nausicaa.camperquake.de>

Hi.

Ovidiu Lixandru <ovidiu at linux360.ro> wrote:

> identity. The desktop now starts by default with a stock GNOME theme 
> which does not include a GTK1 theme

I have to agree with you here. Although I think that clearlooks
is more beautiful than bluecurve, the lack of a GTK1 theme (minor,
since GTK1 is deprecated for FC, but there is lot of use of it in
FE) and more importantly a KDE theme is unfortunate.

-- 
mjh22: "Fucking is bidirectional, at least if you do it right."



From dragoran at feuerpokemon.de  Fri Jul  1 11:43:08 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Fri, 01 Jul 2005 13:43:08 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <1120217974.2772.47.camel@roque>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>	<20050701114422.0de7ca3e@nausicaa.camperquake.de>	<42C518BF.2030802@linux360.ro>
	<1120216547.2772.40.camel@roque>	<42C5292F.3040509@feuerpokemon.de>
	<1120217974.2772.47.camel@roque>
Message-ID: <42C52C4C.3020609@feuerpokemon.de>

Rui Miguel Seabra wrote:

>On Fri, 2005-07-01 at 13:29 +0200, dragoran wrote:
>  
>
>>Rui Miguel Seabra wrote:
>>the problem is that the don't have any other choice ....
>>recommend user to buy older or slower hardware isn't the right way..
>>    
>>
>
>Being held hostage to questionable market moves isn't the right way
>either.
>
>Rui
>
>  
>
I agree but there seems to be no solution :(



From seyman at wanadoo.fr  Fri Jul  1 11:47:41 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 1 Jul 2005 13:47:41 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <42C50F61.2090806@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
Message-ID: <20050701114741.GA6964@orient.maison.moi>

On Fri, Jul 01, 2005 at 12:39:45PM +0300, Ovidiu Lixandru wrote:
> 
> As if BlueCurve were the default theme for GNOME in the RH8 -> FC3 era. 

And the fact that Bluecurve was the default for RH8 -> FC3 doesn't
mean it has to be the default till the end of time. Your arguement
doesn't stand either.

> And that won't work with the NVIDIA binary drivers either. I think this, 
> as well as rhgb, are a waste of developers' time.

I too think that binary drivers are a waste of developers' time.

Emmanuel



From ovidiu at linux360.ro  Fri Jul  1 12:14:24 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Fri, 01 Jul 2005 15:14:24 +0300
Subject: Fedora Core 5 Idea
In-Reply-To: <20050701114741.GA6964@orient.maison.moi>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>
Message-ID: <42C533A0.8020102@linux360.ro>

Emmanuel Seyman wrote:

> And the fact that Bluecurve was the default for RH8 -> FC3 doesn't
> mean it has to be the default till the end of time. Your arguement
> doesn't stand either.

Did I say it has to be BlueCurve? Did I say it has to be any artwork 
"borrowed" from RHEL? I said it should be something professional. 
BlueCurve was and still is in this regard. AFAIK BlueCurve is the *only* 
complete desktop package for GNOME and KDE. It's got 
Qt/GTK1/GTK2/Metacity/KWM themes, icons, wallpapers and mouse pointers 
for both environments. Clearlooks may be a "rewrite", but it's a 5% 
rewrite. There can't be any comparison between the two.

> I too think that binary drivers are a waste of developers' time.

Why should you care, is it FC's developers' time? Are they cr*p? Have a 
look at ATI's, thank you.

-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/476171e4/attachment.bin>

From veillard at redhat.com  Fri Jul  1 12:18:56 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 1 Jul 2005 08:18:56 -0400
Subject: xen, how to boot a 2.4 kernel distro in FC4
In-Reply-To: <1120216702.3519.21.camel@orion>
References: <9d5ddd1f05070103372fbd03f0@mail.gmail.com>
	<1120216702.3519.21.camel@orion>
Message-ID: <20050701121856.GG14660@redhat.com>

On Fri, Jul 01, 2005 at 01:18:21PM +0200, Bob Deblier wrote:
> On Fri, 2005-07-01 at 11:37 +0100, Dan Track wrote:
> > Hi
> > 
> > Can someone please help to find a way, while also getting an
> > understanding as to how to boot a 2.4 kernel distro, in my case rhel
> > 3, as domU under the 2.6 kernel dom0 from FC4.
> > 
> > I'm having problems. Basically I initially though that running a Xen
> > kernel would allow me to boot any os as a domU no matter what their
> > kernel was, but I think I have been mistaken with this. I am running

  No it's not that simple. You would have to compile that 2.4 kernel
to work with Xen. It's is not a matter of just tweaking a config file !

> > into problem while booting this.
> > 
> > I would really appreciate any help provided. 
> 
> As I've mentioned before: the guest OS, i.e. the one running as a domU,
> also needs a specially compiled kernel. See
> http://wiki.xensource.com/xenwiki/XenFaq#head-bb579ddda3999d87064a36b7d847fad8e39440ae
> 
> This is because Xen is a paravirtualizer instead of a full virtualizer,
> like VMware.

  Until Xen3 and the new generation of Intel and AMD CPU offering hardware
support. Check the roadmap for Xen3 at the bottom of

    http://www.cl.cam.ac.uk/Research/SRG/netos/xen/architecture.html

> Wouldn't it be better to ask questions like this on the xen-users list?
> The lack of responses here seems to indicate a general lack of knowledge
> in this topic...

  The suggestion is good, but it's not there is lack of knowledge, rather
that it's 1/ hard 2/ work on old code 3/ would break his RHEL3 support anyway
and there is just too many thing to do to get Xen working smoothly on 
the current kernel that nobody has time to waste on playing with 2.4

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From ovidiu at linux360.ro  Fri Jul  1 12:21:50 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Fri, 01 Jul 2005 15:21:50 +0300
Subject: Fedora Core 5 Idea
In-Reply-To: <42C51F69.70707@redhat.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>	<42C50F61.2090806@linux360.ro>	<42C518A6.3000000@redhat.com>	<42C51CBA.9010507@linux360.ro>
	<42C51F69.70707@redhat.com>
Message-ID: <42C5355E.1030503@linux360.ro>

Rahul Sundaram wrote:

> Again, You should get into the fedora-marketing list and read the 
> discussions there and participate if you have good design skills or even 
> ideas on how to go about making Fedora look attractive and better. It 
> seems you would rather choose your distribution based on the theme and 
> wallpapers rather than switching it over to what fit your tastes better. 
> I am pretty sure any given theme isnt going to please everyone

My hands are full with another Linux project. I just thought an old 
user's opinion could be heard by the great people who develop it and 
perhaps see some bits of truth in it.

-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/0363ee41/attachment.bin>

From seyman at wanadoo.fr  Fri Jul  1 11:54:55 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 1 Jul 2005 13:54:55 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <42C52C4C.3020609@feuerpokemon.de>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114422.0de7ca3e@nausicaa.camperquake.de>
	<42C518BF.2030802@linux360.ro> <1120216547.2772.40.camel@roque>
	<42C5292F.3040509@feuerpokemon.de> <1120217974.2772.47.camel@roque>
	<42C52C4C.3020609@feuerpokemon.de>
Message-ID: <20050701115455.GA7223@orient.maison.moi>

On Fri, Jul 01, 2005 at 01:43:08PM +0200, dragoran wrote:
>
> I agree but there seems to be no solution :(

As a wise man once said:

"Actually, the official position should be to recommend users to avoid
 buying such incompatible hardware, since it's support is minimal."

Emmanuel



From rdieter at math.unl.edu  Fri Jul  1 12:47:27 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 01 Jul 2005 07:47:27 -0500
Subject: Fedora Core 5 Idea
In-Reply-To: <42C50F61.2090806@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>
Message-ID: <da3dim$mih$1@sea.gmane.org>

Ovidiu Lixandru wrote:
> Rahul Sundaram wrote:

>> Already in the wish list. http://fedoraproject.org/wiki/Wishlist. 
>> Personally I like the idea of doing something similar to the early GDM 
>> login and new init script to make bootup faster to apply to shutdown 
>> too so that it not slow enough to add graphics to make the wait look 
>> better
> 
> 
> And that won't work with the NVIDIA binary drivers either. 

How so?

-- Rex



From lamont at gurulabs.com  Fri Jul  1 13:32:52 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 1 Jul 2005 07:32:52 -0600
Subject: Fedora Core 5 Idea
In-Reply-To: <42C518BF.2030802@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<20050701114422.0de7ca3e@nausicaa.camperquake.de>
	<42C518BF.2030802@linux360.ro>
Message-ID: <200507010732.57001.lamont@gurulabs.com>

On Friday 01 July 2005 04:19am, Ovidiu Lixandru wrote:
> Ralf Ertzinger wrote:
[SNIP]
> I didn't say that. I said FC should use its efforts better for the
> benefit of its users. If you develop a program which the majority of the
> desktop users won't use because of *official* driver incompatibility,
> you definitely have some goal issues.

You can not state that Nvidia is used by a "majority of the desktop users".  
That is simply not true.  Far more people are using something else than are 
using Nvidia video cards.

Even if that were true, there would not be any "goal issues" here...where is 
is said that one of Fedora's goals would be to give one hardware vendor an 
advantage over another?  (Rephrase as needed to understand the point).
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/a5c17305/attachment.sig>

From alan at redhat.com  Fri Jul  1 13:36:47 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 1 Jul 2005 09:36:47 -0400
Subject: Fedora Core 5 Idea
In-Reply-To: <200507010732.57001.lamont@gurulabs.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<20050701114422.0de7ca3e@nausicaa.camperquake.de>
	<42C518BF.2030802@linux360.ro>
	<200507010732.57001.lamont@gurulabs.com>
Message-ID: <20050701133647.GB26540@devserv.devel.redhat.com>

On Fri, Jul 01, 2005 at 07:32:52AM -0600, Lamont R. Peterson wrote:
> You can not state that Nvidia is used by a "majority of the desktop users".  
> That is simply not true.  Far more people are using something else than are 
> using Nvidia video cards.

Intel is currently the dominant supplier of video hardware according to the
marketing data I have seen. (Just an FYI)

Alan



From lamont at gurulabs.com  Fri Jul  1 13:36:36 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 1 Jul 2005 07:36:36 -0600
Subject: Fedora Core 5 Idea
In-Reply-To: <42C5292F.3040509@feuerpokemon.de>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<1120216547.2772.40.camel@roque> <42C5292F.3040509@feuerpokemon.de>
Message-ID: <200507010736.41878.lamont@gurulabs.com>

On Friday 01 July 2005 05:29am, dragoran wrote:
> Rui Miguel Seabra wrote:
[SNIP]
> the problem is that the don't have any other choice ....
> recommend user to buy older or slower hardware isn't the right way..

No other choice?  What are you talking about?  There are several other card 
makers out there building video cards for systems.  None of them *force* 
anyone to "buy older or slower hardware".

This is open-source software...IOW, it's all about choice.

Freedom to choose is not just for consumers but also for the hardware 
manufacturers.  They can choose to support or ignore (or somewhere 
in-between) any group of users they choose to.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/f8bcf400/attachment.sig>

From seanlkml at sympatico.ca  Fri Jul  1 13:54:02 2005
From: seanlkml at sympatico.ca (Sean)
Date: Fri, 1 Jul 2005 09:54:02 -0400 (EDT)
Subject: Fedora Core 5 Idea
In-Reply-To: <42C5292F.3040509@feuerpokemon.de>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>	<20050701114422.0de7ca3e@nausicaa.camperquake.de>	<42C518BF.2030802@linux360.ro>
	<1120216547.2772.40.camel@roque> <42C5292F.3040509@feuerpokemon.de>
Message-ID: <4472.10.10.10.24.1120226042.squirrel@10.10.10.104>

On Fri, July 1, 2005 7:29 am, dragoran said:

> the problem is that the don't have any other choice ....
> recommend user to buy older or slower hardware isn't the right way..
>

No, it _is_ the right way.  There _are_ other choices, and they should be
recommended by the community instead of companies that refuse to properly
support Linux.  Especially when many (or most) peoples needs are servered
perfectly well by one of the current open source options.  We _really_
need people who care about open source to stop spreading the notion that
there is no alternative to nVidia.

Cheers,
Sean




From dan.track at gmail.com  Fri Jul  1 14:19:39 2005
From: dan.track at gmail.com (Dan Track)
Date: Fri, 1 Jul 2005 15:19:39 +0100
Subject: xen, how to boot a 2.4 kernel distro in FC4
In-Reply-To: <20050701121856.GG14660@redhat.com>
References: <9d5ddd1f05070103372fbd03f0@mail.gmail.com>
	<1120216702.3519.21.camel@orion> <20050701121856.GG14660@redhat.com>
Message-ID: <9d5ddd1f0507010719d290d5e@mail.gmail.com>

On 7/1/05, Daniel Veillard <veillard at redhat.com> wrote:
> On Fri, Jul 01, 2005 at 01:18:21PM +0200, Bob Deblier wrote:
> > On Fri, 2005-07-01 at 11:37 +0100, Dan Track wrote:
> > > Hi
> > >
> > > Can someone please help to find a way, while also getting an
> > > understanding as to how to boot a 2.4 kernel distro, in my case rhel
> > > 3, as domU under the 2.6 kernel dom0 from FC4.
> > >
> > > I'm having problems. Basically I initially though that running a Xen
> > > kernel would allow me to boot any os as a domU no matter what their
> > > kernel was, but I think I have been mistaken with this. I am running
> 
>   No it's not that simple. You would have to compile that 2.4 kernel
> to work with Xen. It's is not a matter of just tweaking a config file !
> 
> > > into problem while booting this.
> > >
> > > I would really appreciate any help provided.
> >
> > As I've mentioned before: the guest OS, i.e. the one running as a domU,
> > also needs a specially compiled kernel. See
> > http://wiki.xensource.com/xenwiki/XenFaq#head-bb579ddda3999d87064a36b7d847fad8e39440ae
> >
> > This is because Xen is a paravirtualizer instead of a full virtualizer,
> > like VMware.
> 
>   Until Xen3 and the new generation of Intel and AMD CPU offering hardware
> support. Check the roadmap for Xen3 at the bottom of
> 
>     http://www.cl.cam.ac.uk/Research/SRG/netos/xen/architecture.html
> 
> > Wouldn't it be better to ask questions like this on the xen-users list?
> > The lack of responses here seems to indicate a general lack of knowledge
> > in this topic...
> 
>   The suggestion is good, but it's not there is lack of knowledge, rather
> that it's 1/ hard 2/ work on old code 3/ would break his RHEL3 support anyway
> and there is just too many thing to do to get Xen working smoothly on
> the current kernel that nobody has time to waste on playing with 2.4
> 
> Daniel
> 
> --
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
> 

Hi All,

Many thanks for your replies.

Its a bit upsetting that it can't be done. But hey I'm glad I still
spent the time asking because I realised a lot from it.

Much appreciate your help.

Thanks
Dan



From seyman at wanadoo.fr  Fri Jul  1 13:43:25 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 1 Jul 2005 15:43:25 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <42C533A0.8020102@linux360.ro>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>
	<42C533A0.8020102@linux360.ro>
Message-ID: <20050701134325.GA8225@orient.maison.moi>

On Fri, Jul 01, 2005 at 03:14:24PM +0300, Ovidiu Lixandru wrote:
> 
> >I too think that binary drivers are a waste of developers' time.
> 
> Why should you care, is it FC's developers' time?

Yes, it is.

Mike Harris has to spend time explaining to users that he can't fix bugs
in the nvidia driver because he hasn't got the source code. Kernel hackers
have to waste their time with crashes from tainted kernels. In the long
run, all of this adds up and it's time that could be used for better things.

> Are they cr*p? Have a look at ATI's, thank you.

No thanks. I brought an ATI card because the XFree86/Xorg drivers had
good 3D support for them. The whole point was to avoid binary drivers,
to begin with.

Emmanuel



From rjune at bravegnuworld.com  Fri Jul  1 16:06:33 2005
From: rjune at bravegnuworld.com (Richard June)
Date: Fri, 1 Jul 2005 11:06:33 -0500
Subject: Fedora Core 5 Idea
In-Reply-To: <4472.10.10.10.24.1120226042.squirrel@10.10.10.104>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C5292F.3040509@feuerpokemon.de>
	<4472.10.10.10.24.1120226042.squirrel@10.10.10.104>
Message-ID: <200507011106.36106.rjune@bravegnuworld.com>

On Friday 01 July 2005 08:54, Sean wrote:
> On Fri, July 1, 2005 7:29 am, dragoran said:
> > the problem is that the don't have any other choice ....
> > recommend user to buy older or slower hardware isn't the right way..
>
> No, it _is_ the right way.  There _are_ other choices, and they should be
> recommended by the community instead of companies that refuse to properly
> support Linux.  Especially when many (or most) peoples needs are servered
> perfectly well by one of the current open source options.  We _really_
> need people who care about open source to stop spreading the notion that
> there is no alternative to nVidia.
Please, name a video card that performs as well as an nVidia GeForce2 using 
OSS drivers. ATi has some cards in that performance range, but only if you 
use their drivers, which are even worse then nVidias

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050701/99ddb7ab/attachment.sig>

From sundaram at redhat.com  Fri Jul  1 17:07:27 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 01 Jul 2005 22:37:27 +0530
Subject: Fedora Core 5 Idea
In-Reply-To: <200507011106.36106.rjune@bravegnuworld.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C5292F.3040509@feuerpokemon.de>	<4472.10.10.10.24.1120226042.squirrel@10.10.10.104>
	<200507011106.36106.rjune@bravegnuworld.com>
Message-ID: <42C5784F.6080202@redhat.com>

Richard June wrote:

>On Friday 01 July 2005 08:54, Sean wrote:
>  
>
>>On Fri, July 1, 2005 7:29 am, dragoran said:
>>    
>>
>>>the problem is that the don't have any other choice ....
>>>recommend user to buy older or slower hardware isn't the right way..
>>>      
>>>
>>No, it _is_ the right way.  There _are_ other choices, and they should be
>>recommended by the community instead of companies that refuse to properly
>>support Linux.  Especially when many (or most) peoples needs are servered
>>perfectly well by one of the current open source options.  We _really_
>>need people who care about open source to stop spreading the notion that
>>there is no alternative to nVidia.
>>    
>>
>Please, name a video card that performs as well as an nVidia GeForce2 using 
>OSS drivers. ATi has some cards in that performance range, but only if you 
>use their drivers, which are even worse then nVidias
>
>  
>
Would people stop discussing merits and demerits of particular brands of 
video cards and their drivers and market share in the Fedora development 
list. This is definitely off topic for this list. Kindly stop

regards
Rahul



From ph18 at cornell.edu  Fri Jul  1 17:09:17 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Fri, 01 Jul 2005 13:09:17 -0400
Subject: Fedora Core 5 Idea
In-Reply-To: <4472.10.10.10.24.1120226042.squirrel@10.10.10.104>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>	<42C50F61.2090806@linux360.ro>	<20050701114422.0de7ca3e@nausicaa.camperquake.de>	<42C518BF.2030802@linux360.ro>	<1120216547.2772.40.camel@roque>
	<42C5292F.3040509@feuerpokemon.de>
	<4472.10.10.10.24.1120226042.squirrel@10.10.10.104>
Message-ID: <42C578BD.3080102@cornell.edu>

Sean wrote:

>
>No, it _is_ the right way.  There _are_ other choices, and they should be
>recommended by the community instead of companies that refuse to properly
>support Linux.  Especially when many (or most) peoples needs are servered
>perfectly well by one of the current open source options.  We _really_
>need people who care about open source to stop spreading the notion that
>there is no alternative to nVidia.
>  
>
    Yeah,  there's ATI!



From olly at survex.com  Sat Jul  2 00:57:18 2005
From: olly at survex.com (Olly Betts)
Date: Sat, 2 Jul 2005 00:57:18 +0000 (UTC)
Subject: Desktop search tool using lucene
References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl>
	<1119851909.2949.1.camel@localhost.localdomain>
	<20050628161852.GA8866@devserv.devel.redhat.com>
Message-ID: <loom.20050702T024333-648@post.gmane.org>

Alan Cox <alan <at> redhat.com> writes:
> One possibility is the muscat engine - thats open source could probably do the
> job well. It's a little weak on revoking content from the index without a
> rebuild.

Can you elaborate on "weak"?  Nobody's mentioned this to me (the main Xapian
developer), and it's really hard to address problems I don't know about...

Xapian's certainly better than some - for example swish-e can only remove
documents by rebuilding the index (unless you build it with the experimental
--enable-incremental option).  Not meaning to pick on swish-e particularly -
it was just the first example to come to mind.

Cheers,
    Olly



From leonard at den.ottolander.nl  Sat Jul  2 10:27:53 2005
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Sat, 02 Jul 2005 12:27:53 +0200
Subject: [Fwd: mc 4.6.1 pre5 has been released.]
Message-ID: <1120300071.7314.0.camel@athlon.localdomain>

-----Forwarded Message-----
From: Miguel de Icaza <miguel at ximian.com>
To: Leonard den Ottolander <leonard at den.ottolander.nl>
Cc: MC dev <mc-devel at gnome.org>
Subject: mc 4.6.1 pre5 has been released.
Date: Fri, 01 Jul 2005 12:08:49 -0400

Hello,

    A new release of Midnight Commander has been uploaded to:

http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/mc-4.6.1-pre5.tar.gz

    The web site and the ftp site have been uploaded.

    If no major problems are found on this release, this will become
mc-4.6.1

Enjoy,     
Miguel.
-- 
mount -t life -o ro /dev/dna /genetic/research




From buildsys at redhat.com  Sat Jul  2 11:08:19 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 2 Jul 2005 07:08:19 -0400
Subject: rawhide report: 20050702 changes
Message-ID: <200507021108.j62B8Jd5008890@porkchop.devel.redhat.com>

 

 
Updated Packages:

cpio-2.6-8
----------
* Fri Jul 01 2005 Peter Vrabec <pvrabec at redhat.com> 2.6-8
- fix large file support, archive >4GiB, archive members <4GiB (#160056)
- fix race condition holes, use mode 0700 for dir creation

cryptsetup-luks-1.0.1-1
-----------------------
* Fri Jul 01 2005 Bill Nottingham <notting at redhat.com> 1.0.1-1
- update to 1.0.1 - fixes incompatiblity with previous cryptsetup for
  piped passwords

glib2-2.7.1-1
-------------
* Fri Jul 01 2005 Matthias Clasen <mclasen at redhat.com> - 2.7.1-1
- Update to 2.7.1

gnome-applets-1:2.10.1-10
-------------------------
* Fri Jul 01 2005 Mark McLoughlin <markmc at redhat.com> 1:2.10.1-10
- Backport from HEAD patch to remove lame warning dialog when the
  mixer applet can't find a mixer device

hplip-0.9.3-8
-------------
* Fri Jul 01 2005 Tim Waugh <twaugh at redhat.com> 0.9.3-8
- Removed Obsoletes: hpoj tags (bug #162222).

kernel-2.6.12-1.1411_FC5
------------------------
* Fri Jul 01 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc1-git3
  - Xen broke again, so is temporarily disabled. Sorry :(
- Add a vdso marker to /proc/*/maps even if the vDSO is randomized

* Thu Jun 30 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc1-git2

* Wed Jun 29 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc1

openoffice.org-1:1.9.113-1.2.0.fc5
----------------------------------
* Thu Jun 30 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.113-1
- bump to new version
- translations merged, drop translation sources
- hsqldb bumped to version with working build.xml, drop sources
- add patch to work around notorious gcc19870 for hsqldb
- indic font fallbacks now in upstream
- openoffice.org-1.9.92.oooXXXXX.addindic.patch integrated

system-config-printer-0.6.135-1
-------------------------------
* Fri Jul 01 2005 Tim Waugh <twaugh at redhat.com> 0.6.135-1
- 0.6.135:
  - Restore PTAL support, and silence HPLIP errors while probing (bug #162222).

* Thu Jun 16 2005 Tim Waugh <twaugh at redhat.com> 0.6.134-1
- Updated file manifest to include glob patterns for python byte compilation.
- 0.6.134:
  - No code changes.  Rebuilt for python byte compilation.

* Thu Jun 16 2005 Tim Waugh <twaugh at redhat.com> 0.6.133-1
- 0.6.133:
  - No code changes.  Rebuilt for python byte compilation.

Broken deps for i386
----------------------------------------------------------
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	initscripts - 8.11.1-1.ppc64 requires kernel >= 0:2.6
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	gnome-volume-manager - 1.3.1-1.ppc64 requires kernel >= 0:2.6
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	sysstat - 5.0.5-10.fc.ppc64 requires kernel >= 0:2.2.16-21
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	dhcp - 10:3.0.2-14.ppc64 requires kernel >= 0:2.2.18
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	firstboot - 1.3.42-1.noarch requires system-config-display
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	nfs-utils - 1.0.7-8.ppc64 requires kernel >= 0:2.2.14
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	prelink - 0.3.5-1.ppc64 requires kernel >= 0:2.4.10
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	hal - 0.5.2-2.ppc64 requires kernel >= 0:2.6.11
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.8.3-14.ppc64 requires kernel >= 0:2.2.0
	quota - 1:3.12-6.ppc64 requires kernel >= 0:2.4
	rhpl - 0.168-1.ppc64 requires pyxf86config >= 0:0.3.2
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	lvm2 - 2.01.12-1.0.ppc64 requires kernel >= 0:2.6
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	pcmcia-cs - 3.2.8-4.12.ppc64 requires kernel >= 0:2.6.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	gkrellm - 2.2.7-1.ppc64 requires kernel >= 0:2.6.2
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	arptables_jf - 0.0.8-5.ppc64 requires kernel >= 0:2.4.0
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	rp-pppoe - 3.5-28.ppc64 requires kernel >= 0:2.2.9
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3



Broken deps for ppc
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging



Broken deps for x86_64
----------------------------------------------------------
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	rgmanager - 1.9.31-3.ia64 requires ccs
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis



Broken deps for s390
----------------------------------------------------------
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219





From alan at redhat.com  Sat Jul  2 12:17:59 2005
From: alan at redhat.com (Alan Cox)
Date: Sat, 2 Jul 2005 08:17:59 -0400
Subject: Desktop search tool using lucene
In-Reply-To: <loom.20050702T024333-648@post.gmane.org>
References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl>
	<1119851909.2949.1.camel@localhost.localdomain>
	<20050628161852.GA8866@devserv.devel.redhat.com>
	<loom.20050702T024333-648@post.gmane.org>
Message-ID: <20050702121759.GC22629@devserv.devel.redhat.com>

On Sat, Jul 02, 2005 at 12:57:18AM +0000, Olly Betts wrote:
> Xapian's certainly better than some - for example swish-e can only remove
> documents by rebuilding the index (unless you build it with the experimental
> --enable-incremental option).  Not meaning to pick on swish-e particularly -
> it was just the first example to come to mind.

Xapian didnt seem to be returning disk space without a rebuild. Not sure if
that is an index property or not ?




From olly at survex.com  Sun Jul  3 01:01:19 2005
From: olly at survex.com (Olly Betts)
Date: Sun, 3 Jul 2005 01:01:19 +0000 (UTC)
Subject: Desktop search tool using lucene
References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl>
	<1119851909.2949.1.camel@localhost.localdomain>
	<20050628161852.GA8866@devserv.devel.redhat.com>
	<loom.20050702T024333-648@post.gmane.org>
	<20050702121759.GC22629@devserv.devel.redhat.com>
Message-ID: <loom.20050703T024409-839@post.gmane.org>

Alan Cox <alan at redhat.com> writes:
> Xapian didnt seem to be returning disk space without a rebuild. Not sure if
> that is an index property or not ?

Ah yes, that's a feature of the current Btree manager.  The disk space isn't
"leaked", so if you add more documents it'll get reused, but even if you delete
all the documents the index size won't decrease!

However, a full rebuild isn't required to recover the space.  Instead you
can run the index through "quartzcompact" which will reduce it to minimal
size.  Because "quartzcompact" works on the inverted file structure, it's
much faster than a full rebuild would be (it also avoids having to reread
and reparse all the documents).  For example, the approx. 28 million
document Gmane index takes about 45 minutes to compact.  Rebuilding that
takes more like 45 *hours*.

I'm currently working on a new-and-improved backend, having learned a lot
from watching and tinkering with the current one.  Currently it's using
the same Btree manager, but I'm planning to replace that and I'm intending
to allow the file size to shrink in the new one.

Cheers,
    Olly



From mpeters at mac.com  Sun Jul  3 07:18:03 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Sun, 03 Jul 2005 00:18:03 -0700
Subject: Fedora Core 5 Idea
In-Reply-To: <20050701134325.GA8225@orient.maison.moi>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>
	<42C533A0.8020102@linux360.ro>
	<20050701134325.GA8225@orient.maison.moi>
Message-ID: <1120375084.2685.28.camel@locolhost.localdomain>

On Fri, 2005-07-01 at 15:43 +0200, Emmanuel Seyman wrote:
> On Fri, Jul 01, 2005 at 03:14:24PM +0300, Ovidiu Lixandru wrote:
> > 
> > >I too think that binary drivers are a waste of developers' time.
> > 
> > Why should you care, is it FC's developers' time?
> 
> Yes, it is.
> 
> Mike Harris has to spend time explaining to users that he can't fix bugs
> in the nvidia driver because he hasn't got the source code. Kernel hackers
> have to waste their time with crashes from tainted kernels. In the long
> run, all of this adds up and it's time that could be used for better things.

The reality is a LOT of non Fedora controlled Linux websites recommend
NVidia graphics cards for use with Linux. I think that is somewhat
unfortunate, but also is reality.

I don't know of a video card with an open source driver that has the 3D
performance of NVidia, and 3D is really the only reason to run the
nvidia binary drivers anyway (I have no problems with the open source
nvidia drivers for 2D)

If you are going to game in Linux, you need either ATI or NVidia -
unless there is some card with open source 3D drivers I'm not aware of -
and I'm not sure the 3D gaming market in Linux should be ignored by
Fedora.

That being said - there's no reason to let nvidia hold back development,
if something in the boot process doesn't work with nvidia's drivers,
then have an option to disable it. Those who want nvidia can disable it.
Early login should be a boot option, like rhgb, that can be disabled. As
long as that is the case - there's no problem. If that is not the case,
then there is a serious problem with Fedora, non-working xorg.conf
should not interfere with booting a system (and that is why I don't use
rhgb presently)



From buildsys at redhat.com  Sun Jul  3 11:22:25 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 3 Jul 2005 07:22:25 -0400
Subject: rawhide report: 20050703 changes
Message-ID: <200507031122.j63BMPcY004794@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11



Broken deps for s390x
----------------------------------------------------------
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for i386
----------------------------------------------------------
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	sysstat - 5.0.5-10.fc.ppc64 requires kernel >= 0:2.2.16-21
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-volume-manager - 1.3.1-1.ppc64 requires kernel >= 0:2.6
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	firstboot - 1.3.42-1.noarch requires system-config-display
	rhpl - 0.168-1.ppc64 requires pyxf86config >= 0:0.3.2
	hal - 0.5.2-2.ppc64 requires kernel >= 0:2.6.11
	pcmcia-cs - 3.2.8-4.12.ppc64 requires kernel >= 0:2.6.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	initscripts - 8.11.1-1.ppc64 requires kernel >= 0:2.6
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	dhcp - 10:3.0.2-14.ppc64 requires kernel >= 0:2.2.18
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	prelink - 0.3.5-1.ppc64 requires kernel >= 0:2.4.10
	rp-pppoe - 3.5-28.ppc64 requires kernel >= 0:2.2.9
	quota - 1:3.12-6.ppc64 requires kernel >= 0:2.4
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	gkrellm - 2.2.7-1.ppc64 requires kernel >= 0:2.6.2
	nfs-utils - 1.0.7-8.ppc64 requires kernel >= 0:2.2.14
	selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	arptables_jf - 0.0.8-5.ppc64 requires kernel >= 0:2.4.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.8.3-14.ppc64 requires kernel >= 0:2.2.0
	lvm2 - 2.01.12-1.0.ppc64 requires kernel >= 0:2.6





From ivazquez at ivazquez.net  Sun Jul  3 11:34:11 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Sun, 03 Jul 2005 07:34:11 -0400
Subject: Fedora Core 5 Idea
In-Reply-To: <1120375084.2685.28.camel@locolhost.localdomain>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>
	<42C533A0.8020102@linux360.ro>
	<20050701134325.GA8225@orient.maison.moi>
	<1120375084.2685.28.camel@locolhost.localdomain>
Message-ID: <1120390452.26858.3.camel@ignacio.ignacio.lan>

On Sun, 2005-07-03 at 00:18 -0700, Michael A. Peters wrote:
> If you are going to game in Linux, you need either ATI or NVidia -
> unless there is some card with open source 3D drivers I'm not aware of -
> and I'm not sure the 3D gaming market in Linux should be ignored by
> Fedora.

Matrox, but their 3D performance isn't at the same level as ATI or
nVidia.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050703/8b0270bf/attachment.sig>

From mattdm at mattdm.org  Sun Jul  3 13:28:23 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 3 Jul 2005 09:28:23 -0400
Subject: Fedora Core 5 Idea
In-Reply-To: <1120390452.26858.3.camel@ignacio.ignacio.lan>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>
	<42C533A0.8020102@linux360.ro>
	<20050701134325.GA8225@orient.maison.moi>
	<1120375084.2685.28.camel@locolhost.localdomain>
	<1120390452.26858.3.camel@ignacio.ignacio.lan>
Message-ID: <20050703132823.GA27062@jadzia.bu.edu>

On Sun, Jul 03, 2005 at 07:34:11AM -0400, Ignacio Vazquez-Abrams wrote:
> > If you are going to game in Linux, you need either ATI or NVidia -
> > unless there is some card with open source 3D drivers I'm not aware of -
> > and I'm not sure the 3D gaming market in Linux should be ignored by
> > Fedora.
> Matrox, but their 3D performance isn't at the same level as ATI or
> nVidia.

Also the Intel integrated chipsets.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.



From j.w.r.degoede at hhs.nl  Sun Jul  3 16:34:50 2005
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 03 Jul 2005 18:34:50 +0200
Subject: mmap question
Message-ID: <42C813AA.2080404@hhs.nl>

Hi all,

I'm busy trying to package svgalib-1.9.x for Fedora-Extras (I know I'm 
also mailing to devel). And I've hit a bit of a bump.

svgalib-1.9.x mmap's part of the linear framebuffer at the same address 
each time vga_setpage gets called. This is done for cards which are not 
100% vga compatible, so that old programs which expect to see banked 
modes will get banked modes emulated.

The problem with this is that in order todo this svgalib leaves the fd 
for /dev/mem open. Which of course is a big nono from a security point 
of view. So I've been tracking all uses of the /dev/mem fd and I'm 
almost so far that it can be closed immediatly after calling vga_init or 
vga_setmode, as it used to be done in the 1.4.x series.

The setpage emulation on linearframebuffers is the last problem I have. 
What I would like todo is:
open /dev/mem
mmap the entire lfb
close /dev/mem
mmap part of the lfb (64k) at a random address, using the mmap of the
  entire lfb as source instead of an fd.
mmap another part of the lfb (64k) at the address the previous part had.

So what I want is something like mremap, which will allow me to:
-specify a new offset into the file instead of a new size.
or a mmap which will take an existing mapping as source rather then an fd.

Thus such a beast exist and or can anyone help me with another solution?

Thanks & Regards,

Hans



From arjanv at redhat.com  Sun Jul  3 16:53:57 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sun, 03 Jul 2005 18:53:57 +0200
Subject: mmap question
In-Reply-To: <42C813AA.2080404@hhs.nl>
References: <42C813AA.2080404@hhs.nl>
Message-ID: <1120409637.3164.55.camel@laptopd505.fenrus.org>


> The problem with this is that in order todo this svgalib leaves the fd 
> for /dev/mem open. Which of course is a big nono from a security point 
> of view.

In fedora that's actually not THAT bad actually; still not too good tho

As for your question; there is a fremap which may do what you want, but
the use of it is a bit tricky sort of so I'm not sure if you really want
to do that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050703/5c6e112a/attachment.sig>

From bernie at develer.com  Sun Jul  3 18:01:34 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Sun, 03 Jul 2005 20:01:34 +0200
Subject: Fedora Core 5 Idea
In-Reply-To: <1120375084.2685.28.camel@locolhost.localdomain>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>	<20050701114741.GA6964@orient.maison.moi>	<42C533A0.8020102@linux360.ro>	<20050701134325.GA8225@orient.maison.moi>
	<1120375084.2685.28.camel@locolhost.localdomain>
Message-ID: <42C827FE.4010708@develer.com>

Michael A. Peters wrote:

> I don't know of a video card with an open source driver that has the 3D
> performance of NVidia, and 3D is really the only reason to run the
> nvidia binary drivers anyway (I have no problems with the open source
> nvidia drivers for 2D)

I don't want to start a flame war here, but the r200 open-source
driver is *very* fast and very high quality.

The current CVS code from Mesa and DRI is even better than what
we have in Xorg 6.8.2.  Doom 3 runs nicely and it's quite fast.

Even though glxgears isn't a comrehensive benchmark suite, I'd
like to point out that I get 2800-3000 fps with a Radeon 8500
card using the latest CVS code.  NVidia cards usually score
less than 2000 fps.

Then I switched to a Radeon 9600 card with the reverse-engineered
r300 driver developed on SourceForge.  This driver already renders
quake, doom and many other programs correctly, altough it's not
yet as fast as the r200 driver was, and there are outstanding
security and stability problems that prevent merging this code
back into DRI and Mesa.

So at this time I'd recommend Radeon cards to Linux users because
their OSS drivers are very good.  We all hope one day NVidia will
publish their source code or enough documentation to add 3D support
to the nv driver.  If not, the r300 project showed that a
reverse-engineering approach isn't impossible.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From j.w.r.degoede at hhs.nl  Sun Jul  3 19:56:36 2005
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 03 Jul 2005 21:56:36 +0200
Subject: mmap question
In-Reply-To: <1120409637.3164.55.camel@laptopd505.fenrus.org>
References: <42C813AA.2080404@hhs.nl>
	<1120409637.3164.55.camel@laptopd505.fenrus.org>
Message-ID: <42C842F4.3090308@hhs.nl>



Arjan van de Ven wrote:
>>The problem with this is that in order todo this svgalib leaves the fd 
>>for /dev/mem open. Which of course is a big nono from a security point 
>>of view.
> 
> 
> In fedora that's actually not THAT bad actually; still not too good tho
> 
Could you explain this a bit?

> As for your question; there is a fremap which may do what you want, but
> the use of it is a bit tricky sort of so I'm not sure if you really want
> to do that.
> 
Hmm, that might to the trick, why wouldn't I want todo that?
And what about doing tricks with /proc/self/mem?

Thanks ! & Regards,

Hans



From arjanv at redhat.com  Sun Jul  3 21:13:18 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sun, 03 Jul 2005 23:13:18 +0200
Subject: mmap question
In-Reply-To: <42C842F4.3090308@hhs.nl>
References: <42C813AA.2080404@hhs.nl>
	<1120409637.3164.55.camel@laptopd505.fenrus.org>
	<42C842F4.3090308@hhs.nl>
Message-ID: <1120425198.3164.67.camel@laptopd505.fenrus.org>

On Sun, 2005-07-03 at 21:56 +0200, Hans de Goede wrote:
> 
> Arjan van de Ven wrote:
> >>The problem with this is that in order todo this svgalib leaves the fd 
> >>for /dev/mem open. Which of course is a big nono from a security point 
> >>of view.
> > 
> > 
> > In fedora that's actually not THAT bad actually; still not too good tho
> > 
> Could you explain this a bit?

try doing "interesting" things with /dev/mem and you'll see what I
mean ;)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050703/abe69ffc/attachment.sig>

From Fedora at TQMcube.com  Mon Jul  4 01:19:16 2005
From: Fedora at TQMcube.com (David Cary Hart)
Date: Sun, 03 Jul 2005 21:19:16 -0400
Subject: Info Feed RSS Fails to Load
Message-ID: <1120439956.27067.7.camel@dch.TQMcube.com>

http://fedoraproject.org/infofeed/
-- 
      * Eliminate Spam:         http://www.TQMcube.com/spam_trap.htm
      * RBLDNSD HowTo:          http://www.TQMcube.com/rbldnsd.htm
      * Multi-RBL Check:        http://www.TQMcube.com/rblcheck.htm



From skvidal at phy.duke.edu  Mon Jul  4 01:26:29 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 03 Jul 2005 21:26:29 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <1120439956.27067.7.camel@dch.TQMcube.com>
References: <1120439956.27067.7.camel@dch.TQMcube.com>
Message-ID: <1120440389.4617.105.camel@cutter>

On Sun, 2005-07-03 at 21:19 -0400, David Cary Hart wrote:
> http://fedoraproject.org/infofeed/

fails to load how? It loads for me? Which reader/interface?

-sv




From b.j.smith at ieee.org  Mon Jul  4 01:33:06 2005
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Sun, 03 Jul 2005 20:33:06 -0500
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <20050703160030.E8D6772F56@hormel.redhat.com>
References: <20050703160030.E8D6772F56@hormel.redhat.com>
Message-ID: <1120440786.4569.9.camel@bert64.mobile.smithconcepts.com>

From: Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
> Matrox, but their 3D performance isn't at the same level as ATI or
> nVidia.

Umm, last time I checked, Matrox's GLX drivers were _proprietary_ too.  
They just don't have the Intel-nVidia Trade Secret memory interface that
requires the kernel module.

The UtahGLX for Matrox leaves much to be desired (as with the ATI,
although not quite as bad).

From: Matthew Miller <mattdm at mattdm.org>
> Also the Intel integrated chipsets.

Capable of running Tux Racer is not a good test.  Intel's GLX is rather
pathetic in features -- like an order of magnitude.

FRANKLY, I _TIRE_ OF THESE THREADS.

I know it starts off with someone questioning why Fedora doesn't support
nVidia's Standardware (Open Standard, Closed Source) "nvidia" driver.
And I don't blame many in the Fedora team taking offense to the
suggestion.  I think there should be a "standard response" adopted, and
the _known_ fact that it will _not_ be discussed.  That would go a long
way to getting people to be more understanding of the technical fact why
the Fedora Project can and will do _nothing_ to support people who use
the "nvidia" driver.

On the other hand, I _tire_ of some of the more almost "bigotry-like"
and quite _wholly_inaccurate_ responses I do see from Fedora volunteers.
Some of the technical comments are just wholly _incorrect_, and that's
why I got involved the last time this thread came around.  Especially
the "praise" of ATI who is _just_as_proprietary_ on 3D as of R300+ (and
even more so on their 2D because of all the motion video capabilities of
their GPUs).

To re-iterate ...
I really think a "standard response" is needed when people bring it up. 

Especially when a lot of the responses people are making who are part of
the Fedora Project on nVidia could almost be considered "libelous" in
nature -- let alone it personally pisses me off to see the technical
ignorance as an engineer.  You can dislike nVidia and make many
statements that are accurate.  But some of the technically _in_accurate
statements are not only unfair to nVidia, but some of the blind "vendor
loyalty" around here is just a joke if you actually _knew_ something
about ATI, Matrox, etc... and their similarities to nVidia.


-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->




From Fedora at TQMcube.com  Mon Jul  4 01:41:52 2005
From: Fedora at TQMcube.com (David Cary Hart)
Date: Sun, 03 Jul 2005 21:41:52 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <1120440389.4617.105.camel@cutter>
References: <1120439956.27067.7.camel@dch.TQMcube.com>
	<1120440389.4617.105.camel@cutter>
Message-ID: <1120441312.27067.9.camel@dch.TQMcube.com>

On Sun, 2005-07-03 at 21:26 -0400, seth vidal wrote:
> On Sun, 2005-07-03 at 21:19 -0400, David Cary Hart wrote:
> > http://fedoraproject.org/infofeed/
> 
> fails to load how? It loads for me? Which reader/interface?
> 
Firefox. 
-- 
      * Eliminate Spam:         http://www.TQMcube.com/spam_trap.htm
      * RBLDNSD HowTo:          http://www.TQMcube.com/rbldnsd.htm
      * Multi-RBL Check:        http://www.TQMcube.com/rblcheck.htm



From skvidal at phy.duke.edu  Mon Jul  4 01:46:21 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 03 Jul 2005 21:46:21 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <1120441312.27067.9.camel@dch.TQMcube.com>
References: <1120439956.27067.7.camel@dch.TQMcube.com>
	<1120440389.4617.105.camel@cutter>
	<1120441312.27067.9.camel@dch.TQMcube.com>
Message-ID: <1120441581.4617.107.camel@cutter>

On Sun, 2005-07-03 at 21:41 -0400, David Cary Hart wrote:
> On Sun, 2005-07-03 at 21:26 -0400, seth vidal wrote:
> > On Sun, 2005-07-03 at 21:19 -0400, David Cary Hart wrote:
> > > http://fedoraproject.org/infofeed/
> > 
> > fails to load how? It loads for me? Which reader/interface?
> > 
> Firefox. 

how does it fail to load?

-sv



From Fedora at TQMcube.com  Mon Jul  4 02:05:48 2005
From: Fedora at TQMcube.com (David Cary Hart)
Date: Sun, 03 Jul 2005 22:05:48 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <1120441581.4617.107.camel@cutter>
References: <1120439956.27067.7.camel@dch.TQMcube.com>
	<1120440389.4617.105.camel@cutter>
	<1120441312.27067.9.camel@dch.TQMcube.com>
	<1120441581.4617.107.camel@cutter>
Message-ID: <1120442748.27067.19.camel@dch.TQMcube.com>

On Sun, 2005-07-03 at 21:46 -0400, seth vidal wrote:
> On Sun, 2005-07-03 at 21:41 -0400, David Cary Hart wrote:
> > On Sun, 2005-07-03 at 21:26 -0400, seth vidal wrote:
> > > On Sun, 2005-07-03 at 21:19 -0400, David Cary Hart wrote:
> > > > http://fedoraproject.org/infofeed/
> > > 
> > > fails to load how? It loads for me? Which reader/interface?
> > > 
> > Firefox. 
> 
> how does it fail to load?
> 
"Live Bookmark Feed Failed to Load." 

All the others load just fine. The feed link (detected by Firefox) is
http://fedoraproject.org/infofeed/rss20.xml and I can bring up that
page. 

Strange but let's not make this a bfd. I just mentioned it as a FYI.
It's probably a Firefox anomaly. BTW, I just added the feed so it's not
something that worked in the past. 
-- 
      * Eliminate Spam:         http://www.TQMcube.com/spam_trap.htm
      * RBLDNSD HowTo:          http://www.TQMcube.com/rbldnsd.htm
      * Multi-RBL Check:        http://www.TQMcube.com/rblcheck.htm



From subsolar at subsolar.com  Mon Jul  4 02:11:31 2005
From: subsolar at subsolar.com (Paul)
Date: Sun, 03 Jul 2005 21:11:31 -0500
Subject: OT - Re: Fedora Core 5 Idea
In-Reply-To: <42C827FE.4010708@develer.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>	<42C533A0.8020102@linux360.ro>
	<20050701134325.GA8225@orient.maison.moi>
	<1120375084.2685.28.camel@locolhost.localdomain>
	<42C827FE.4010708@develer.com>
Message-ID: <1120443091.4870.9.camel@localhost>

On Sun, 2005-07-03 at 20:01 +0200, Bernardo Innocenti wrote:
> Michael A. Peters wrote:
> 
> > I don't know of a video card with an open source driver that has the 3D
> > performance of NVidia, and 3D is really the only reason to run the
> > nvidia binary drivers anyway (I have no problems with the open source
> > nvidia drivers for 2D)
> 
> I don't want to start a flame war here, but the r200 open-source
> driver is *very* fast and very high quality.

Maybe I should revisit them on my old 9000 card ... when I used to use
them they did not do mult-texturing and did not support s3tc compressed
textures.   I don't believe the texture compression issue is fixed
because of patent issues.

> The current CVS code from Mesa and DRI is even better than what
> we have in Xorg 6.8.2.  Doom 3 runs nicely and it's quite fast.
> 
> Even though glxgears isn't a comrehensive benchmark suite, I'd
> like to point out that I get 2800-3000 fps with a Radeon 8500
> card using the latest CVS code.  NVidia cards usually score
> less than 2000 fps.

Hmmm I'm getting the following on a nVida 5700 Ultra (a far from top
range nVidia Card)
[subsolar at azure ~]$ glxgears
20495 frames in 5.0 seconds = 4099.000 FPS
27532 frames in 5.0 seconds = 5506.400 FPS
27474 frames in 5.0 seconds = 5494.800 FPS
27347 frames in 5.0 seconds = 5469.400 FPS
27244 frames in 5.0 seconds = 5448.800 FPS

Regards,
Paul



From caillon at redhat.com  Mon Jul  4 03:57:34 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sun, 03 Jul 2005 23:57:34 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <1120442748.27067.19.camel@dch.TQMcube.com>
References: <1120439956.27067.7.camel@dch.TQMcube.com>	<1120440389.4617.105.camel@cutter>	<1120441312.27067.9.camel@dch.TQMcube.com>	<1120441581.4617.107.camel@cutter>
	<1120442748.27067.19.camel@dch.TQMcube.com>
Message-ID: <42C8B3AE.9030606@redhat.com>

On 07/03/2005 10:05 PM, David Cary Hart wrote:

>On Sun, 2005-07-03 at 21:46 -0400, seth vidal wrote:
>  
>
>>On Sun, 2005-07-03 at 21:41 -0400, David Cary Hart wrote:
>>    
>>
>>>On Sun, 2005-07-03 at 21:26 -0400, seth vidal wrote:
>>>      
>>>
>>>>On Sun, 2005-07-03 at 21:19 -0400, David Cary Hart wrote:
>>>>        
>>>>
>>>>>http://fedoraproject.org/infofeed/
>>>>>          
>>>>>
>>>>fails to load how? It loads for me? Which reader/interface?
>>>>
>>>>        
>>>>
>>>Firefox. 
>>>      
>>>
>>how does it fail to load?
>>
>>    
>>
>"Live Bookmark Feed Failed to Load." 
>
>All the others load just fine. The feed link (detected by Firefox) is
>http://fedoraproject.org/infofeed/rss20.xml and I can bring up that
>page. 
>
>Strange but let's not make this a bfd. I just mentioned it as a FYI.
>It's probably a Firefox anomaly. BTW, I just added the feed so it's not
>something that worked in the past. 
>  
>
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Ffedoraproject.org%2Finfofeed%2Frss20.xml

I think it needs valid RSS in order to work.



From skvidal at phy.duke.edu  Mon Jul  4 04:06:15 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 04 Jul 2005 00:06:15 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <42C8B3AE.9030606@redhat.com>
References: <1120439956.27067.7.camel@dch.TQMcube.com>
	<1120440389.4617.105.camel@cutter>
	<1120441312.27067.9.camel@dch.TQMcube.com>
	<1120441581.4617.107.camel@cutter>
	<1120442748.27067.19.camel@dch.TQMcube.com>
	<42C8B3AE.9030606@redhat.com>
Message-ID: <1120449975.4617.111.camel@cutter>


> >Strange but let's not make this a bfd. I just mentioned it as a FYI.
> >It's probably a Firefox anomaly. BTW, I just added the feed so it's not
> >something that worked in the past. 
> >  
> >
> http://feedvalidator.org/check.cgi?url=http%3A%2F%2Ffedoraproject.org%2Finfofeed%2Frss20.xml
> 
> I think it needs valid RSS in order to work.


odd - it works fine for me in liferea and firefox.

-sv




From caillon at redhat.com  Mon Jul  4 04:10:25 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 04 Jul 2005 00:10:25 -0400
Subject: Info Feed RSS Fails to Load
In-Reply-To: <1120449975.4617.111.camel@cutter>
References: <1120439956.27067.7.camel@dch.TQMcube.com>	<1120440389.4617.105.camel@cutter>	<1120441312.27067.9.camel@dch.TQMcube.com>	<1120441581.4617.107.camel@cutter>	<1120442748.27067.19.camel@dch.TQMcube.com>	<42C8B3AE.9030606@redhat.com>
	<1120449975.4617.111.camel@cutter>
Message-ID: <42C8B6B1.2020200@redhat.com>

On 07/04/2005 12:06 AM, seth vidal wrote:

>>>Strange but let's not make this a bfd. I just mentioned it as a FYI.
>>>It's probably a Firefox anomaly. BTW, I just added the feed so it's not
>>>something that worked in the past. 
>>> 
>>>
>>>      
>>>
>>http://feedvalidator.org/check.cgi?url=http%3A%2F%2Ffedoraproject.org%2Finfofeed%2Frss20.xml
>>
>>I think it needs valid RSS in order to work.
>>    
>>
>
>
>odd - it works fine for me in liferea and firefox.
>
>-sv
>  
>
Since the poster was a little vague as to what's broken, here's a 
clarification:

* Load http://fedoraproject.org/infofeed/
* In the lower right corner of the browser window, click the RSS icon 
(its the orange icon on the browser chrome - where the lock icon would be)
* Click Subscribe to RSS
* Click OK.
* Bookmarks menu > Fedora Info > ....

Here, it should list all of the articles in the feed, but doesn't.  Try 
the above steps with Fedora People for example, Planet GNOME, 
caillon.blog, etc. to see the desired behavior.



From bernie at develer.com  Mon Jul  4 04:26:25 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Mon, 04 Jul 2005 06:26:25 +0200
Subject: OT - Re: Fedora Core 5 Idea
In-Reply-To: <1120443091.4870.9.camel@localhost>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>	<42C44549.8060706@redhat.com>
	<42C50F61.2090806@linux360.ro>	<20050701114741.GA6964@orient.maison.moi>	<42C533A0.8020102@linux360.ro>	<20050701134325.GA8225@orient.maison.moi>	<1120375084.2685.28.camel@locolhost.localdomain>	<42C827FE.4010708@develer.com>
	<1120443091.4870.9.camel@localhost>
Message-ID: <42C8BA71.8050604@develer.com>

Paul wrote:

>>I don't want to start a flame war here, but the r200 open-source
>>driver is *very* fast and very high quality.
> 
> Maybe I should revisit them on my old 9000 card ... when I used to use
> them they did not do mult-texturing and did not support s3tc compressed
> textures.   I don't believe the texture compression issue is fixed
> because of patent issues.

GL_ARB_multitexture is supported in new Mesa, but I'm not
sure if it's accelerated on r200.

s3tc _is_ supported for radeon, r200 and Intel chipsets,
altough encumbered code is kept in a separate library to
avoid legal problems for Mesa:

  http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html


>>Even though glxgears isn't a comrehensive benchmark suite, I'd
>>like to point out that I get 2800-3000 fps with a Radeon 8500
>>card using the latest CVS code.  NVidia cards usually score
>>less than 2000 fps.
> 
> Hmmm I'm getting the following on a nVida 5700 Ultra (a far from top
> range nVidia Card)
> [subsolar at azure ~]$ glxgears
> 20495 frames in 5.0 seconds = 4099.000 FPS
> 27532 frames in 5.0 seconds = 5506.400 FPS
> 27474 frames in 5.0 seconds = 5494.800 FPS
> 27347 frames in 5.0 seconds = 5469.400 FPS
> 27244 frames in 5.0 seconds = 5448.800 FPS

Oops, perhaps I've been avoing NVidia cards for too
long :-)

BTW, NVidia is the only binary driver for Linux that
doesn't suck and works fine even with latest versions
of the kernel.

(that's just a technical consideration, it doesn't
mean we should all be depending on it).

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From mpaesold at gmx.at  Mon Jul  4 08:18:06 2005
From: mpaesold at gmx.at (Michael Paesold)
Date: Mon, 4 Jul 2005 10:18:06 +0200
Subject: Has anyone got rhel3 running under fc4 as a domu
References: <9d5ddd1f05063007381ffee524@mail.gmail.com>
Message-ID: <00c101c58070$e921b500$0f01a8c0@zaphod>

Dan Track wrote:

> Hi,
>
> I'm looking for someone who can help me get rhel3 running under fc4 as
> a domU.

I am using it with the fc4 domU kernel without problems. There are messages 
at boot time that several kernel modules could not be loaded, but that is to 
be expected and causes no problems. E.g. the hardware clock is usually 
unaccessible for a domU in xen.

So perhaps you could try the domU instead of the dom0 kernel for the rhel3 
guest.

Best Regards,
Michael Paesold 



From sundaram at redhat.com  Mon Jul  4 09:06:21 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 04 Jul 2005 14:36:21 +0530
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120440786.4569.9.camel@bert64.mobile.smithconcepts.com>
References: <20050703160030.E8D6772F56@hormel.redhat.com>
	<1120440786.4569.9.camel@bert64.mobile.smithconcepts.com>
Message-ID: <42C8FC0D.40108@redhat.com>

Bryan J. Smith wrote:

>From: Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
>  
>
>>Matrox, but their 3D performance isn't at the same level as ATI or
>>nVidia.
>>    
>>
>
>Umm, last time I checked, Matrox's GLX drivers were _proprietary_ too.  
>They just don't have the Intel-nVidia Trade Secret memory interface that
>requires the kernel module.
>
>The UtahGLX for Matrox leaves much to be desired (as with the ATI,
>although not quite as bad).
>
>From: Matthew Miller <mattdm at mattdm.org>
>  
>
>>Also the Intel integrated chipsets.
>>    
>>
>
>Capable of running Tux Racer is not a good test.  Intel's GLX is rather
>pathetic in features -- like an order of magnitude.
>
>FRANKLY, I _TIRE_ OF THESE THREADS.
>
Then stop discussing it. 

regards
Rahul



From dragoran at feuerpokemon.de  Mon Jul  4 09:40:15 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 04 Jul 2005 11:40:15 +0200
Subject: no powernow-k8 in kernel-2.6.12-1.1387_FC4
Message-ID: <42C903FF.900@feuerpokemon.de>

which has this module been removed?



From mpeters at mac.com  Mon Jul  4 10:04:51 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Mon, 04 Jul 2005 03:04:51 -0700
Subject: OT - Re: Fedora Core 5 Idea
In-Reply-To: <42C8BA71.8050604@develer.com>
References: <BAY103-F16BDA9B6731EA3A715E79FE1E30@phx.gbl>
	<42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro>
	<20050701114741.GA6964@orient.maison.moi>
	<42C533A0.8020102@linux360.ro>
	<20050701134325.GA8225@orient.maison.moi>
	<1120375084.2685.28.camel@locolhost.localdomain>
	<42C827FE.4010708@develer.com> <1120443091.4870.9.camel@localhost>
	<42C8BA71.8050604@develer.com>
Message-ID: <1120471491.2656.12.camel@locolhost.localdomain>

On Mon, 2005-07-04 at 06:26 +0200, Bernardo Innocenti wrote:

> 
> BTW, NVidia is the only binary driver for Linux that
> doesn't suck and works fine even with latest versions
> of the kernel.

Every time I try it - there still are issues.
last time, grep would segfault under certain conditions, for example -
and other apps (such as balsa) would sometimes stall during startup for
long periods - solved be reverting to nv.ko

It's usable, sure - but it is definitely not as stable as open source
drivers.
So I don't do any 3d games in Linux anymore - I'm not much of a gamer
anyway. Tuxracer was nice though to play with.



From dan.track at gmail.com  Mon Jul  4 10:32:23 2005
From: dan.track at gmail.com (Dan Track)
Date: Mon, 4 Jul 2005 11:32:23 +0100
Subject: Has anyone got rhel3 running under fc4 as a domu
In-Reply-To: <00c101c58070$e921b500$0f01a8c0@zaphod>
References: <9d5ddd1f05063007381ffee524@mail.gmail.com>
	<00c101c58070$e921b500$0f01a8c0@zaphod>
Message-ID: <9d5ddd1f05070403325c29fbfd@mail.gmail.com>

> Dan Track wrote:
> 
> Hi,
>
> I'm looking for someone who can help me get rhel3 running under fc4 as
> a domU.
> 
> I am using it with the fc4 domU kernel without problems. There are messages
> at boot time that several kernel modules could not be loaded, but that is to
> be expected and causes no problems. E.g. the hardware clock is usually
> unaccessible for a domU in xen.
> 
> So perhaps you could try the domU instead of the dom0 kernel for the rhel3
> guest.
> 
> Best Regards,
> Michael Paesold

Hi

Thanks for the reply.

I've tried using the domU, here's my config:

kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU"
ramdisk = "/boot/initrd-2.6.11-1.1369_FC4xenU.img"
memory = 260
name = "rhel-3-es"
nics = 1
disk = ['phy:hda3,sda1,w']
root = "/dev/sda1 ro"

Any chance you could post your configs and how you installed rhel3.

Many Thanks
Dan



From buildsys at redhat.com  Mon Jul  4 11:08:50 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 4 Jul 2005 07:08:50 -0400
Subject: rawhide report: 20050704 changes
Message-ID: <200507041108.j64B8o7h027970@porkchop.devel.redhat.com>

 

 
Updated Packages:

eclipse-1:3.1.0_fc-1
--------------------
* Tue Jun 28 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-1
- Import 3.1.
- Update splash screen.

* Sun Jun 26 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-0.RC4.1
- Import 3.1 RC4.
- Remove activeHelpSample.jar building patch as it's now fixed upstream.
- Add patch to remove references to cairo since we don't have it in FC4.
- Add about.html and about_files to eclipse-platform.install (x86 & x86_64).
- Add patch to create public compare API (jpound - e.o#98707).
- Add patch from Robin Green to not look for firefox libxpcom.so (rh#161658).
- Symlink lucene jars (rh#159939).

file-4.13-5
-----------
* Mon Jul 04 2005 Radek Vokal <rvokal at redhat.com> - 4.14-5
- fixed reiserfs check (#162378)

* Mon Apr 11 2005 Radek Vokal <rvokal at redhat.com> - 4.13-4
- check Cyrus files before Apple Quicktime movies (#154342)

* Mon Mar 07 2005 Radek Vokal <rvokal at redhat.com> - 4.13-3
- check for shared libs before fs dump files (#149868)

foomatic-3.0.2-21
-----------------
* Sun Jul 03 2005 Tim Waugh <twaugh at redhat.com> 3.0.2-21
- Updated db to 20050703.

gjdoc-0.7.5-2
-------------
* Sun Jul 03 2005 Andrew Overholt <overholt at redhat.com> 0.7.5-2
- Add patches for processing imports in the correct order and for correct
  behaviour when a resolved import is not found (both from Tom Tromey).

pychecker-0.8.14-5
------------------
* Tue Jun 28 2005 Miloslav Trmac <mitr at redhat.com> - 0.8.14-5
- Don't ship documentation in the python*/site-packages
- Rely on redhat-rpm-config for .py[co] generation
- Backport a fix for spurious warnings about divisions
- Disable warning about mismatch of implicit and explicit returns, it has too
  many false positives with Python 2.4
- Fix handling of functions with no known return value
- Fix handling of tuple literals

rp-pppoe-3.5-29
---------------
* Mon Jul 04 2005 Than Ngo <than at redhat.com> 3.5-29 
- fix broken dependencies

selinux-policy-strict-1.24-2
----------------------------
* Sat Jul 02 2005 Dan Walsh <dwalsh at redhat.com> 1.24-2
- Allow getty to run pppd
- Allow netplugd to work

selinux-policy-targeted-1.24-2
------------------------------
* Sat Jul 02 2005 Dan Walsh <dwalsh at redhat.com> 1.24-2
- Allow getty to run pppd
- Allow netplugd to work

Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for i386
----------------------------------------------------------
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10



Broken deps for ppc64
----------------------------------------------------------
	arptables_jf - 0.0.8-5.ppc64 requires kernel >= 0:2.4.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	nfs-utils - 1.0.7-8.ppc64 requires kernel >= 0:2.2.14
	prelink - 0.3.5-1.ppc64 requires kernel >= 0:2.4.10
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	libpcap - 14:0.8.3-14.ppc64 requires kernel >= 0:2.2.0
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	rhpl - 0.168-1.ppc64 requires pyxf86config >= 0:0.3.2
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	gkrellm - 2.2.7-1.ppc64 requires kernel >= 0:2.6.2
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	dhcp - 10:3.0.2-14.ppc64 requires kernel >= 0:2.2.18
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	gnome-volume-manager - 1.3.1-1.ppc64 requires kernel >= 0:2.6
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	sysstat - 5.0.5-10.fc.ppc64 requires kernel >= 0:2.2.16-21
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	hal - 0.5.2-2.ppc64 requires kernel >= 0:2.6.11
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	initscripts - 8.11.1-1.ppc64 requires kernel >= 0:2.6
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	firstboot - 1.3.42-1.noarch requires system-config-display
	quota - 1:3.12-6.ppc64 requires kernel >= 0:2.4
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.12-1.0.ppc64 requires kernel >= 0:2.6
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	pcmcia-cs - 3.2.8-4.12.ppc64 requires kernel >= 0:2.6.0



Broken deps for ia64
----------------------------------------------------------
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	rgmanager - 1.9.31-3.ia64 requires ccs
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging



Broken deps for s390
----------------------------------------------------------
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging





From rms at 1407.org  Mon Jul  4 09:52:26 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 04 Jul 2005 10:52:26 +0100
Subject: no powernow-k8 in kernel-2.6.12-1.1387_FC4
In-Reply-To: <42C903FF.900@feuerpokemon.de>
References: <42C903FF.900@feuerpokemon.de>
Message-ID: <1120470746.2846.19.camel@roque>

On Mon, 2005-07-04 at 11:40 +0200, dragoran wrote:
> which has this module been removed?

Lucky you. I wasn't able to boot at all :)

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050704/9d91263c/attachment.sig>

From mpaesold at gmx.at  Mon Jul  4 12:42:08 2005
From: mpaesold at gmx.at (Michael Paesold)
Date: Mon, 4 Jul 2005 14:42:08 +0200
Subject: Has anyone got rhel3 running under fc4 as a domu
References: <9d5ddd1f05063007381ffee524@mail.gmail.com>
	<00c101c58070$e921b500$0f01a8c0@zaphod>
	<9d5ddd1f05070403325c29fbfd@mail.gmail.com>
Message-ID: <0b8901c58095$cb0aeb20$0f01a8c0@zaphod>

Dan Track wrote:
> Michael Paesold wrote:
> > So perhaps you could try the domU instead of the dom0 kernel for
> > the rhel3 guest.
>
>
> Hi
>
> Thanks for the reply.
>
> I've tried using the domU, here's my config:
>
> kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU"
> ramdisk = "/boot/initrd-2.6.11-1.1369_FC4xenU.img"
> memory = 260
> name = "rhel-3-es"
> nics = 1
> disk = ['phy:hda3,sda1,w']
> root = "/dev/sda1 ro"
>
> Any chance you could post your configs and how you installed rhel3.

The only real difference here is that I did not use an initial ram disk. I 
do not see a reason that it would be useful because the unprivileged domain 
cannot access any hardware directly, and so will need no additional device 
drivers.

Regarding the installation of RHEL3, I did use CentOS-3 instead. The main 
reason beeing that you can boostrap a CentOS-3 installation using yum in a 
chroot environment; I could not find a way to do this using up2date.

I created this installation on a regular CentOS-3 machine, than used tar to 
copy the whole installation and extracted it into the mounted root partition 
for the domU.

See here for ways to install a guest:
http://lists.xensource.com/archives/html/xen-users/2005-04/msg00329.html

In general I would recommend to use rather RHEL4 as I recommend using a 2.6 
kernel with xen, and not a 2.4 one. Still if you need RHEL3, I've had not 
problems with the 2.6 kernel by now.

If you still have problems, you should probably post to the xen-users list 
including detailed information of error output.

Best Regards,
Michael Paesold



From ad+lists at uni-x.org  Mon Jul  4 12:43:47 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Mon, 04 Jul 2005 14:43:47 +0200
Subject: no powernow-k8 in kernel-2.6.12-1.1387_FC4
In-Reply-To: <42C903FF.900@feuerpokemon.de>
References: <42C903FF.900@feuerpokemon.de>
Message-ID: <1120481027.20667.164.camel@serendipity.dogma.lan>

Am Mo, den 04.07.2005 schrieb dragoran um 11:40:

> which has this module been removed?

Compiled statically into the kernel. Check your
/boot/config-2.6.12-1.1387_FC4.

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp 
Serendipity 14:42:35 up 8 days, 21:34, load average: 0.40, 0.29, 0.13 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050704/8e3f4d74/attachment.sig>

From dan.track at gmail.com  Mon Jul  4 13:08:16 2005
From: dan.track at gmail.com (Dan Track)
Date: Mon, 4 Jul 2005 14:08:16 +0100
Subject: Has anyone got rhel3 running under fc4 as a domu
In-Reply-To: <0b8901c58095$cb0aeb20$0f01a8c0@zaphod>
References: <9d5ddd1f05063007381ffee524@mail.gmail.com>
	<00c101c58070$e921b500$0f01a8c0@zaphod>
	<9d5ddd1f05070403325c29fbfd@mail.gmail.com>
	<0b8901c58095$cb0aeb20$0f01a8c0@zaphod>
Message-ID: <9d5ddd1f0507040608f98a17@mail.gmail.com>

Hi Michael,

Thanks for that.

Where did you get the 2.4 kernel from. Because it doesn't come with FC4?

Thanks
Dan

On 7/4/05, Michael Paesold <mpaesold at gmx.at> wrote:
> Dan Track wrote:
> > Michael Paesold wrote:
> > > So perhaps you could try the domU instead of the dom0 kernel for
> > > the rhel3 guest.
> >
> >
> > Hi
> >
> > Thanks for the reply.
> >
> > I've tried using the domU, here's my config:
> >
> > kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU"
> > ramdisk = "/boot/initrd-2.6.11-1.1369_FC4xenU.img"
> > memory = 260
> > name = "rhel-3-es"
> > nics = 1
> > disk = ['phy:hda3,sda1,w']
> > root = "/dev/sda1 ro"
> >
> > Any chance you could post your configs and how you installed rhel3.
> 
> The only real difference here is that I did not use an initial ram disk. I
> do not see a reason that it would be useful because the unprivileged domain
> cannot access any hardware directly, and so will need no additional device
> drivers.
> 
> Regarding the installation of RHEL3, I did use CentOS-3 instead. The main
> reason beeing that you can boostrap a CentOS-3 installation using yum in a
> chroot environment; I could not find a way to do this using up2date.
> 
> I created this installation on a regular CentOS-3 machine, than used tar to
> copy the whole installation and extracted it into the mounted root partition
> for the domU.
> 
> See here for ways to install a guest:
> http://lists.xensource.com/archives/html/xen-users/2005-04/msg00329.html
> 
> In general I would recommend to use rather RHEL4 as I recommend using a 2.6
> kernel with xen, and not a 2.4 one. Still if you need RHEL3, I've had not
> problems with the 2.6 kernel by now.
> 
> If you still have problems, you should probably post to the xen-users list
> including detailed information of error output.
> 
> Best Regards,
> Michael Paesold
> 
>



From alan at redhat.com  Mon Jul  4 15:57:00 2005
From: alan at redhat.com (Alan Cox)
Date: Mon, 4 Jul 2005 11:57:00 -0400
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120440786.4569.9.camel@bert64.mobile.smithconcepts.com>
References: <20050703160030.E8D6772F56@hormel.redhat.com>
	<1120440786.4569.9.camel@bert64.mobile.smithconcepts.com>
Message-ID: <20050704155700.GB24792@devserv.devel.redhat.com>

On Sun, Jul 03, 2005 at 08:33:06PM -0500, Bryan J. Smith wrote:
> Umm, last time I checked, Matrox's GLX drivers were _proprietary_ too.  
> They just don't have the Intel-nVidia Trade Secret memory interface that
> requires the kernel module.

G4xx DRI is open source. Parhelia (has anyone even seen one ???) is not

> Capable of running Tux Racer is not a good test.  Intel's GLX is rather
> pathetic in features -- like an order of magnitude.

If it runs tuxracer and bzflag then I'm happy ;) As to Intel's GLX it has 
fairly good features on the i915 including vertex shaders and it will get
better over time.



From mattdm at mattdm.org  Mon Jul  4 16:10:45 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 4 Jul 2005 12:10:45 -0400
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <20050704155700.GB24792@devserv.devel.redhat.com>
References: <20050703160030.E8D6772F56@hormel.redhat.com>
	<1120440786.4569.9.camel@bert64.mobile.smithconcepts.com>
	<20050704155700.GB24792@devserv.devel.redhat.com>
Message-ID: <20050704161045.GA4560@jadzia.bu.edu>

On Mon, Jul 04, 2005 at 11:57:00AM -0400, Alan Cox wrote:
> > Umm, last time I checked, Matrox's GLX drivers were _proprietary_ too.  
> > They just don't have the Intel-nVidia Trade Secret memory interface that
> > requires the kernel module.
> G4xx DRI is open source. Parhelia (has anyone even seen one ???) is not

Yeah I saw one on the shelf of a friend's office gathering dust. :)

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 76 degrees Fahrenheit.



From b.j.smith at ieee.org  Mon Jul  4 16:24:35 2005
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 04 Jul 2005 11:24:35 -0500
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <20050704100557.2D428735AB@hormel.redhat.com>
References: <20050704100557.2D428735AB@hormel.redhat.com>
Message-ID: <1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>

From: Rahul Sundaram <sundaram at redhat.com>
> Then stop discussing it. 

Ummm ... that was my _only_ post in this thread!
I don't think my disgust for this thread is any less than yours.
So don't blame me.  ;->

The last time this came up, I finally said something when some people
would not end their technical ignorance.  Then I got chastized or
demonized for merely pointing out that the responses were just as bad as
the request.  Which is why I stated out of this thread.

Again, while I also don't believe the Fedora team should have to deal
with this request, I also don't think some people on the Fedora team
don't have to make technical statements which just aren't true, and more
politically-aligned assumptions.

So, once again, I think it's about time that there is a "standard
response" on this issue, and whenever it comes up again, that is _all_
the team gives.  Because the level of bigotry and non-truth in some of
the responses is just disgusting.

Almost as bad as the original requests.


-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->




From sundaram at redhat.com  Mon Jul  4 16:27:09 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 04 Jul 2005 21:57:09 +0530
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
References: <20050704100557.2D428735AB@hormel.redhat.com>
	<1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
Message-ID: <42C9635D.5080709@redhat.com>

Hi

>So, once again, I think it's about time that there is a "standard
>response" on this issue, and whenever it comes up again, that is _all_
>the team gives.  
>
Standard response for Fedora has always been no support for any 
proprietary or legally encumbered software.

http://fedoraproject.org/wiki/ForbiddenItems

regards
Rahul



From jimhayward at earthlink.net  Mon Jul  4 16:41:01 2005
From: jimhayward at earthlink.net (Jim Hayward)
Date: Mon, 04 Jul 2005 09:41:01 -0700
Subject: FC4 x84_64, GCC4.0 link error
Message-ID: <1120495261.2996.49.camel@garfield.linux.localdomain>

Hi All,

Can anyone give me an good, understandable explanation of exactly what
this error means and how it might be fixed. I did a google search, I get
quite a few hits, but nothing that gives a really good explanation. If I
add -fPIC and recompile it does work around the compile problem. But I
would like to know why.

/usr/bin/ld: cap.o: relocation R_X86_64_32 can not be used when making
a shared object; recompile with -fPIC cap.o: could not read symbols:
Bad value collect2: ld returned 1 exit status


Regards,
	Jim H
-- 
Jim Hayward <jimhayward at earthlink.net>
GPG Key available at: http://keyserver.noreply.org
gpg --recv-keys --keyserver keyserver.noreply.org 0x85A92DCC
GPG Fingerprint: 1AA9 AEC9 BFDF FF7A E4F8 90C7 4947 3A41 85A9 2DCC 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050704/b84cee98/attachment.sig>

From jakub at redhat.com  Mon Jul  4 16:48:43 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 4 Jul 2005 12:48:43 -0400
Subject: FC4 x84_64, GCC4.0 link error
In-Reply-To: <1120495261.2996.49.camel@garfield.linux.localdomain>
References: <1120495261.2996.49.camel@garfield.linux.localdomain>
Message-ID: <20050704164843.GP15087@devserv.devel.redhat.com>

On Mon, Jul 04, 2005 at 09:41:01AM -0700, Jim Hayward wrote:
> Hi All,
> 
> Can anyone give me an good, understandable explanation of exactly what
> this error means and how it might be fixed. I did a google search, I get
> quite a few hits, but nothing that gives a really good explanation. If I
> add -fPIC and recompile it does work around the compile problem. But I
> would like to know why.
> 
> /usr/bin/ld: cap.o: relocation R_X86_64_32 can not be used when making
> a shared object; recompile with -fPIC cap.o: could not read symbols:
> Bad value collect2: ld returned 1 exit status

Including position dependent code in shared libraries is wrong on all
architectures.  On some architectures it is only slow, insecure and
prohibits sharing of shared library code pages, but works unless SELinux
prohibits it (e.g. i386), on some architectures the same applies, but
it only sort of works (i.e. you have to be lucky that libraries are
mapped close to each other, e.g. ppc32).  On other architectures
non-PIC code is forbidden altogether in shared libraries (e.g. x86-64).

	Jakub



From drepper at redhat.com  Mon Jul  4 16:52:55 2005
From: drepper at redhat.com (Ulrich Drepper)
Date: Mon, 04 Jul 2005 09:52:55 -0700
Subject: mmap question
In-Reply-To: <42C813AA.2080404@hhs.nl>
References: <42C813AA.2080404@hhs.nl>
Message-ID: <42C96967.1030605@redhat.com>

Hans de Goede wrote:
> open /dev/mem
> mmap the entire lfb
> close /dev/mem
> mmap part of the lfb (64k) at a random address, using the mmap of the
>  entire lfb as source instead of an fd.
> mmap another part of the lfb (64k) at the address the previous part had.

Just like this, it is not possible.  mmap always uses a file descriptor.

The closest technique to what you describe is the remap_file_pages()
function.  No file descriptor needed and you can remap parts of a
previously mmap()ed area to other file offsets, on a per-page basis.
I.e., map for instance 128k initially, then you can map the
128k/pagesize pages of the map each to a different offset of the
underlying "file".

And no, you cannot use /proc/self/mem for any of this.  mmap of
/proc/self/mem is not possible.

-- 
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050704/54f9b853/attachment.sig>

From spam at tachegroup.com  Mon Jul  4 23:03:20 2005
From: spam at tachegroup.com (TGS)
Date: Mon, 4 Jul 2005 19:03:20 -0400
Subject: Build system - how to ?
Message-ID: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>

Where can I find information on the build system for Fedora?



From b.j.smith at ieee.org  Tue Jul  5 00:49:00 2005
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 04 Jul 2005 19:49:00 -0500
Subject: Fedora Core 5 Idea -- "Forbidden Items" ...
Message-ID: <1120524540.4770.11.camel@bert64.mobile.smithconcepts.com>

Rahul Sundaram wrote:  
> Standard response for Fedora has always been no support for any
> proprietary or legally encumbered software.
> http://fedoraproject.org/wiki/ForbiddenItems

Excellent!  That's _exactly_ what the Fedora team should be quoting.
Let's proliferate the idea to just answer all inquires with this and
leave it at that.

-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->




From aoliva at redhat.com  Tue Jul  5 04:20:47 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 05 Jul 2005 01:20:47 -0300
Subject: Why are (unencrypted) DVD players forbidden?
In-Reply-To: <42C9635D.5080709@redhat.com>
References: <20050704100557.2D428735AB@hormel.redhat.com>
	<1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
	<42C9635D.5080709@redhat.com>
Message-ID: <orll4levds.fsf_-_@livre.redhat.lsd.ic.unicamp.br>

On Jul  4, 2005, Rahul Sundaram <sundaram at redhat.com> wrote:

> Standard response for Fedora has always been no support for any
> proprietary or legally encumbered software.

> http://fedoraproject.org/wiki/ForbiddenItems

I don't think DVD playing software should be included in this list.
In fact, there's no point in not including software that can play
unencrypted DVDs, for those who have their own unencrypted content, or
those who live in places where DVD encryption is not even legal.

Getting the code that uses the decryption machinery present in DVD
drives into a separate, dlopen()able shared library should be pretty
easy.  I bet someone has already done that ;-)

So what's the excuse to not include such nice software as Ogle and
libdvdread (but not libdvdcss)?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From seanlkml at sympatico.ca  Tue Jul  5 04:27:36 2005
From: seanlkml at sympatico.ca (Sean)
Date: Tue, 5 Jul 2005 00:27:36 -0400 (EDT)
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
References: <20050704100557.2D428735AB@hormel.redhat.com>
	<1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
Message-ID: <1856.10.10.10.24.1120537656.squirrel@linux1>

On Mon, July 4, 2005 12:24 pm, Bryan J. Smith said:
> From: Rahul Sundaram <sundaram at redhat.com>
>> Then stop discussing it.
>
> Ummm ... that was my _only_ post in this thread!
> I don't think my disgust for this thread is any less than yours.
> So don't blame me.  ;->
>
> The last time this came up, I finally said something when some people
> would not end their technical ignorance.  Then I got chastized or
> demonized for merely pointing out that the responses were just as bad as
> the request.  Which is why I stated out of this thread.
>
> Again, while I also don't believe the Fedora team should have to deal
> with this request, I also don't think some people on the Fedora team
> don't have to make technical statements which just aren't true, and more
> politically-aligned assumptions.
>
> So, once again, I think it's about time that there is a "standard
> response" on this issue, and whenever it comes up again, that is _all_
> the team gives.  Because the level of bigotry and non-truth in some of
> the responses is just disgusting.
>
> Almost as bad as the original requests.
>

Your love affair with nVidia is all well and good and your cheerleading
for them is okay for your own needs.  However, supporting binary drivers
just doesn't help move open source solutions ahead.   We need more people
to stand up and support open source drivers, especially since they're good
enough already for the vast majority of uses.

If Intel or someone else gets extra business via their open source
offerings it will put a little extra pressure on those in the industry who
refuse to do so.   We already lost ATI supported open source drivers,
quite possibly because so many fanboys went around supporting nVidia
afterward and saying binary drivers were just as good as open source.

We need more people who believe in open source to stand up and spread the
word and not listen to all the nVidia fan boys so much.

Sean





From dragoran at feuerpokemon.de  Tue Jul  5 05:21:56 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Tue, 05 Jul 2005 07:21:56 +0200
Subject: no powernow-k8 in kernel-2.6.12-1.1387_FC4
In-Reply-To: <1120481027.20667.164.camel@serendipity.dogma.lan>
References: <42C903FF.900@feuerpokemon.de>
	<1120481027.20667.164.camel@serendipity.dogma.lan>
Message-ID: <42CA18F4.2070104@feuerpokemon.de>

Alexander Dalloz wrote:

>Am Mo, den 04.07.2005 schrieb dragoran um 11:40:
>
>  
>
>>which has this module been removed?
>>    
>>
>
>Compiled statically into the kernel. Check your
>/boot/config-2.6.12-1.1387_FC4.
>
>Alexander
>
>
>  
>
ok
thx ;)



From ivazquez at ivazquez.net  Tue Jul  5 05:28:53 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 01:28:53 -0400
Subject: gcc cross-compiler for mipsel
Message-ID: <1120541334.15363.41.camel@ignacio.ignacio.lan>

I'm currently trying to build a cross-compiler toolchain for mipsel
based on the packages in FC4, and I'm getting the following message when
running configure for gcc:

/usr/mipsel-linux/bin/as: symbol lookup error: /usr/mipsel-linux/bin/as:
undefined symbol: bfd_mips16_num_opcodes

The binutils package I'm using is located here:

http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec
http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src.rpm

My current gcc-mipsel-minimal specfile, rpmbuild log, and
obj-mipsel-linux/gcc/config.log are located here:

http://fedora.ivazquez.net/files/current/

Does anyone have any idea what is going on, or where I should go for
further assistance?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/0f834c0e/attachment.sig>

From notting at redhat.com  Tue Jul  5 05:43:03 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 5 Jul 2005 01:43:03 -0400
Subject: Why are (unencrypted) DVD players forbidden?
In-Reply-To: <orll4levds.fsf_-_@livre.redhat.lsd.ic.unicamp.br>
References: <20050704100557.2D428735AB@hormel.redhat.com>
	<1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
	<42C9635D.5080709@redhat.com>
	<orll4levds.fsf_-_@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20050705054303.GA18908@nostromo.devel.redhat.com>

Alexandre Oliva (aoliva at redhat.com) said: 
> So what's the excuse to not include such nice software as Ogle and
> libdvdread (but not libdvdcss)?

MPEG2 (and AC3, IIRC) are both patented. Which makes it pretty
much a moot point.

Bill



From b.j.smith at ieee.org  Tue Jul  5 06:24:37 2005
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 05 Jul 2005 01:24:37 -0500
Subject: Fedora Core 5 Idea -- let's drop this ...
Message-ID: <1120544677.5362.15.camel@bert64.mobile.smithconcepts.com>

Sean wrote: 
> Your love affair with nVidia is all well and good and your
> cheerleading for them is okay for your own needs.

This is the "bigotry" crap I'm talking about!
I did *0* so-called "cheerleading" in this thread.

God damn can't people stop and not make it about "versus" and
"draw a line in the sand?"  Especially when they don't know
what they are drawing the line about?!

No offense, but I'm _very_sorry_ I even tried to take a few moments
as "explain a few things" in a _previous_ thread.  And in this
thread, I did _not_ say _anything_ about nVidia!

All I said was that to continue to "debate" is to continue to
introduce _technically_ *FALSE* information, often based on 
assumption, disregard for some real, technical accuracy.
The problem with advocacy is that it tends to introduce statements
of political alignment and _not_ technical reality, so _avoid_ them.

I think the single line Rahul posted is fine and does the job.
Let's leave it at that.

Otherwise I think my intelligence has had enough insult.


-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->




From b.j.smith at ieee.org  Tue Jul  5 06:41:15 2005
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 05 Jul 2005 01:41:15 -0500
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120544677.5362.15.camel@bert64.mobile.smithconcepts.com>
References: <1120544677.5362.15.camel@bert64.mobile.smithconcepts.com>
Message-ID: <1120545675.5362.25.camel@bert64.mobile.smithconcepts.com>

On Tue, 2005-07-05 at 01:24 -0500, Bryan J. Smith wrote:
> God damn can't people stop and not make it about "versus" and
> "draw a line in the sand?"  Especially when they don't know
> what they are drawing the line about?!

I really mean this ... it seems like "double" or even "triple"
standards are applied to some vendors, and the presumed "support"
of so-called "open source."

ATI (as of the R300+) has turned into an even more proprietary vendor
than nVidia in many respects.  Matrox never really supported anything
but their proprietary drivers, and even support of those has waned
more recently.

Now if people could actually "nail down" a set of "criteria" to say
"oh, you're helping open source" then I'd actually be more "open"
to this whole "debate."

But to date, that has _not_ happened.  It's been general assumptions,
general "oh, now we're talking brand X, instead of brand Y, so brand
X has line A we hold them against, instead of the normal line B we
hold brand Y against."

And worst of all, because I'm the stupid schmuck that actually tried
to explain some things in the last thread, I'm now labeled a "nVidia
cheerleader."  Man, it's funny, but I'm actually quite the _opposite_.
I only tried to take the time to explain different things in a
previous thread, and _only_ after the thread had gone well on long
enough to the point where people like yourself were stating half-
truths and false assumptions.

If someone has a support question, and it is about something that
the Fedora Team cannot support, just leave it at Rahul's link -- and
not some poor attempt at an advocacy campaign that doesn't even have
a well-defined set of criteria.

But if you really find you need to attempt to do so, then by all
means, go ahead.  Try to make the ATI, Matrox, etc... square peg
fit in the round open source hole -- because if I think you start
holding _all_ vendors to the _same_ criteria, you're going to be
quite disappointed.


-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->




From rc040203 at freenet.de  Tue Jul  5 06:46:53 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 05 Jul 2005 08:46:53 +0200
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120541334.15363.41.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
Message-ID: <1120546013.6657.253.camel@mccallum.corsepiu.local>

On Tue, 2005-07-05 at 01:28 -0400, Ignacio Vazquez-Abrams wrote:
> I'm currently trying to build a cross-compiler toolchain for mipsel
> based on the packages in FC4, and I'm getting the following message when
> running configure for gcc:
> 
> /usr/mipsel-linux/bin/as: symbol lookup error: /usr/mipsel-linux/bin/as:
> undefined symbol: bfd_mips16_num_opcodes
Wild guess (Without having tried to build your packages):

Your binutils seem to be dynamically linked against libbfd.
At runtime you therefore get the libbfd as being shipped by FC, not the
version having been built as part of your toolchain built.

I would assume statically linking your binutils against the libbfd
having been build during building your toolchain (--disable-shared) will
fix this issue.

Another possibility would be to install your toolchain's libbfd outside
of /usr/lib into a target dependent directory and to apply rpath during
linkage.

Finally you could consider to use a different prefix (!= /usr).

> The binutils package I'm using is located here:
> 
> http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec
> http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src.rpm
> 
> My current gcc-mipsel-minimal specfile, rpmbuild log, and
> obj-mipsel-linux/gcc/config.log are located here:
> 
> http://fedora.ivazquez.net/files/current/
> 
> Does anyone have any idea what is going on, or where I should go for
> further assistance?

The GCC list, the binutils list, the crossgcc list probably are
appropriate.

Also, I'd assume there are enough toolchain developers on this list and
on Extras.

Ralf







From seanlkml at sympatico.ca  Tue Jul  5 07:42:46 2005
From: seanlkml at sympatico.ca (Sean)
Date: Tue, 5 Jul 2005 03:42:46 -0400 (EDT)
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120545675.5362.25.camel@bert64.mobile.smithconcepts.com>
References: <1120544677.5362.15.camel@bert64.mobile.smithconcepts.com>
	<1120545675.5362.25.camel@bert64.mobile.smithconcepts.com>
Message-ID: <3673.10.10.10.24.1120549366.squirrel@linux1>

On Tue, July 5, 2005 2:41 am, Bryan J. Smith said:
> On Tue, 2005-07-05 at 01:24 -0500, Bryan J. Smith wrote:
>> God damn can't people stop and not make it about "versus" and
>> "draw a line in the sand?"  Especially when they don't know
>> what they are drawing the line about?!
>
> I really mean this ... it seems like "double" or even "triple"
> standards are applied to some vendors, and the presumed "support"
> of so-called "open source."
>
> ATI (as of the R300+) has turned into an even more proprietary vendor
> than nVidia in many respects.  Matrox never really supported anything
> but their proprietary drivers, and even support of those has waned
> more recently.
>
> Now if people could actually "nail down" a set of "criteria" to say
> "oh, you're helping open source" then I'd actually be more "open"
> to this whole "debate."
>
> But to date, that has _not_ happened.  It's been general assumptions,
> general "oh, now we're talking brand X, instead of brand Y, so brand
> X has line A we hold them against, instead of the normal line B we
> hold brand Y against."
>
> And worst of all, because I'm the stupid schmuck that actually tried
> to explain some things in the last thread, I'm now labeled a "nVidia
> cheerleader."  Man, it's funny, but I'm actually quite the _opposite_.
> I only tried to take the time to explain different things in a
> previous thread, and _only_ after the thread had gone well on long
> enough to the point where people like yourself were stating half-
> truths and false assumptions.
>
> If someone has a support question, and it is about something that
> the Fedora Team cannot support, just leave it at Rahul's link -- and
> not some poor attempt at an advocacy campaign that doesn't even have
> a well-defined set of criteria.
>
> But if you really find you need to attempt to do so, then by all
> means, go ahead.  Try to make the ATI, Matrox, etc... square peg
> fit in the round open source hole -- because if I think you start
> holding _all_ vendors to the _same_ criteria, you're going to be
> quite disappointed.
>

There is no double standard in using and promoting open source drivers. 
There are already open source drivers today that can do the job for the
vast majority of cases.  Let's not let the nVidia brand loyalists obscure
the message that there are open source drivers available today that will
do the job well for many situations.  Let's not let this message be
diluted by people who care more about brand loyalty to nVidia than they do
about promoting open source solutions.   Maybe, just maybe, there will be
enough market pressure to encourage further open source choices.

Cheers,
Sean




From dragoran at feuerpokemon.de  Tue Jul  5 10:12:38 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Tue, 05 Jul 2005 12:12:38 +0200
Subject: kernel ignores pci device 
Message-ID: <42CA5D16.7050104@feuerpokemon.de>

I have a tvcard with a saa7134 chip which worked find in fc4 i386.
now running on amd64 I get during boot:
PCI: device 0000:02:08.0 has unknown header type 7f, ignoring.
and can't see it in lspci.
I am using kernel-2.6.12-1.1387_FC4
Should I fill a bug?
Or is something missconfigured?



From fedora at camperquake.de  Tue Jul  5 10:22:46 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 5 Jul 2005 12:22:46 +0200
Subject: Why are (unencrypted) DVD players forbidden?
In-Reply-To: <orll4levds.fsf_-_@livre.redhat.lsd.ic.unicamp.br>
References: <20050704100557.2D428735AB@hormel.redhat.com>
	<1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
	<42C9635D.5080709@redhat.com>
	<orll4levds.fsf_-_@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20050705102246.GA24084@ryoko.camperquake.de>

On Tue, Jul 05, 2005 at 01:20:47AM -0300, Alexandre Oliva wrote:

> Getting the code that uses the decryption machinery present in DVD
> drives into a separate, dlopen()able shared library should be pretty
> easy.  I bet someone has already done that ;-)

libdvdread can dlopen() libdvdcss, yes.



From buildsys at redhat.com  Tue Jul  5 11:14:19 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 5 Jul 2005 07:14:19 -0400
Subject: rawhide report: 20050705 changes
Message-ID: <200507051114.j65BEJou006617@porkchop.devel.redhat.com>

New package perseus-cache
	Perseus cache component

New package perseus-dependency
	Perseus dependency component

New package perseus-distribution
	Perseus distribution component


 
Updated Packages:

avalon-logkit-0:1.2-3jpp_1fc
----------------------------
* Mon Jul 04 2005 Gary Benson <gbenson at redhat.com> 0:1.2-3jpp_1fc
- Reenable building of classes that require jms.
- Build with servletapi5.

eclipse-1:3.1.0_fc-2
--------------------
* Mon Jul 04 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-2
- Remove remaining pre-built ant jars (but don't symlink to ant.jar until we
  have ant 1.6.5 - rh#162444).
- Bump requirement on gcc to get fix for rh#158614.
- Add patch to not try to link to external javadocs and include the javadoc
  output in the build output.
- Add build and runtime requirement on ant-javamail (I'm not sure how we missed
  this previously).

* Mon Jul 04 2005 Gary Benson <gbenson at redhat.com> 3.1.0_fc-2
- Disable classpath access rules introduced in e.o#92398 (rh#162177).

kernel-2.6.12-1.1413_FC5
------------------------
* Mon Jul 04 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc1-git6

man-pages-2.05-1
----------------
* Mon Jul 04 2005 Jiri Ryska <jryska at redhat.com> 2.05-1
- update to 2.05
- atanh(3) fix
- issue(5) fix
- ldd(1) fix
- removed man1p/{compress,uncompress,renice}.1p

* Mon Apr 04 2005 Jiri Ryska <jryska at redhat.com> 1.67-7
- io_setup() and io_destroy() pages now refers to header file
- fixed types for struct shmid_ds in shmget(2) and shmctl(2)
- fixed pages for readv(2) and writev(2)

* Mon Mar 07 2005 Jindrich Novy <jnovy at redhat.com> 1.67-6
- unify fs.5 patches together to get rid of the bogus
  fs.5.orig.gz shipped among man5 pages
- bump release to 6 to avoid conflicts with RHEL4/FC3 man-pages

openoffice.org-1:1.9.114-1.2.0.fc5
----------------------------------
* Mon Jul 04 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.114-1
- bump to next version

pm-utils-0.02-1
---------------

Broken deps for s390
----------------------------------------------------------
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for i386
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219



Broken deps for ppc
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	nfs-utils - 1.0.7-8.ia64 requires kernel >= 0:2.2.14
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	pcmcia-cs - 3.2.8-4.12.ia64 requires kernel >= 0:2.6.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	quota - 1:3.12-6.ia64 requires kernel >= 0:2.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hal - 0.5.2-2.ia64 requires kernel >= 0:2.6.11
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0
	gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	rgmanager - 1.9.31-3.ia64 requires ccs
	lvm2 - 2.01.12-1.0.ia64 requires kernel >= 0:2.6
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	xorg-x11 - 6.8.2-40.ia64 requires kernel-drm = 0:4.3.0
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	dhcp - 10:3.0.2-14.ia64 requires kernel >= 0:2.2.18
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	libpcap - 14:0.8.3-14.ia64 requires kernel >= 0:2.2.0



Broken deps for x86_64
----------------------------------------------------------
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_3fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_3fc.noarch requires regexp
	nfs-utils - 1.0.7-8.ppc64 requires kernel >= 0:2.2.14
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	selinux-policy-targeted-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.2-2.ppc64 requires kernel >= 0:2.6.11
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	arptables_jf - 0.0.8-5.ppc64 requires kernel >= 0:2.4.0
	rhpl - 0.168-1.ppc64 requires pyxf86config >= 0:0.3.2
	lvm2 - 2.01.12-1.0.ppc64 requires kernel >= 0:2.6
	pcmcia-cs - 3.2.8-4.12.ppc64 requires kernel >= 0:2.6.0
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	libpcap - 14:0.8.3-14.ppc64 requires kernel >= 0:2.2.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	initscripts - 8.11.1-1.ppc64 requires kernel >= 0:2.6
	dhcp - 10:3.0.2-14.ppc64 requires kernel >= 0:2.2.18
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	prelink - 0.3.5-1.ppc64 requires kernel >= 0:2.4.10
	selinux-policy-targeted - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	gnome-volume-manager - 1.3.1-1.ppc64 requires kernel >= 0:2.6
	selinux-policy-strict-sources - 1.24-2.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.ppc64 requires kernel >= 0:2.6.2
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	sysstat - 5.0.5-10.fc.ppc64 requires kernel >= 0:2.2.16-21
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	quota - 1:3.12-6.ppc64 requires kernel >= 0:2.4
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	firstboot - 1.3.42-1.noarch requires system-config-display
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3





From b.j.smith at ieee.org  Tue Jul  5 12:26:10 2005
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 05 Jul 2005 07:26:10 -0500
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <20050705101305.DE4C17381F@hormel.redhat.com>
References: <20050705101305.DE4C17381F@hormel.redhat.com>
Message-ID: <1120566370.5362.59.camel@bert64.mobile.smithconcepts.com>

From: "Sean" <seanlkml at sympatico.ca>
> There is no double standard in using and promoting open source drivers. 
> There are already open source drivers today that can do the job for the
> vast majority of cases.  Let's not let the nVidia brand loyalists obscure
> the message that there are open source drivers available today that will
> do the job well for many situations.  Let's not let this message be
> diluted by people who care more about brand loyalty to nVidia than they do
> about promoting open source solutions.   Maybe, just maybe, there will be
> enough market pressure to encourage further open source choices.

Actually, you just re-enforced the double-standard, and just made my
points for me entirely.  ;->

-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->




From ml2news at optonline.net  Tue Jul  5 12:32:32 2005
From: ml2news at optonline.net (Mathieu Chouquet-Stringer)
Date: Tue, 05 Jul 2005 08:32:32 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120541334.15363.41.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
Message-ID: <m3zmt1a0wv.fsf@mcs.bigip.mine.nu>

ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) writes:
> I'm currently trying to build a cross-compiler toolchain for mipsel
> based on the packages in FC4, and I'm getting the following message when
> running configure for gcc:

Have you looked at crosstool? The tarball has probably patches for your
architecture/version.

http://kegel.com/crosstool

-- 
Mathieu Chouquet-Stringer
    "Le disparu, si l'on v?n?re sa m?moire, est plus pr?sent et
                 plus puissant que le vivant".
           -- Antoine de Saint-Exup?ry, Citadelle --



From seanlkml at sympatico.ca  Tue Jul  5 12:48:46 2005
From: seanlkml at sympatico.ca (Sean)
Date: Tue, 5 Jul 2005 08:48:46 -0400 (EDT)
Subject: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <1120566370.5362.59.camel@bert64.mobile.smithconcepts.com>
References: <20050705101305.DE4C17381F@hormel.redhat.com>
	<1120566370.5362.59.camel@bert64.mobile.smithconcepts.com>
Message-ID: <2234.10.10.10.24.1120567726.squirrel@linux1>

On Tue, July 5, 2005 8:26 am, Bryan J. Smith said:
> From: "Sean" <seanlkml at sympatico.ca>
>> There is no double standard in using and promoting open source drivers.
>> There are already open source drivers today that can do the job for the
>> vast majority of cases.  Let's not let the nVidia brand loyalists
>> obscure
>> the message that there are open source drivers available today that will
>> do the job well for many situations.  Let's not let this message be
>> diluted by people who care more about brand loyalty to nVidia than they
>> do
>> about promoting open source solutions.   Maybe, just maybe, there will
>> be
>> enough market pressure to encourage further open source choices.
>
> Actually, you just re-enforced the double-standard, and just made my
> points for me entirely.  ;->
>

Huh?  You're reading something between the lines that just isn't there. 
Anyway, let's do as Rahul asked before your first post on this thread, and
let it go.

Cheers,
Sean




From casimiro.barreto at gmail.com  Tue Jul  5 12:59:48 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 05 Jul 2005 09:59:48 -0300
Subject: Is there a bug in UFS system (ufs=sunx86)
Message-ID: <42CA8444.5050204@gmail.com>

Hello,

Last week I had to install a Solaris 10 partition in a developent
workstation. Whenever I try to mount the solaris partition:

/dev/hdd1          /Solaris               ufs           
ufs=sunx86,ro    0  0

I get a system error (invalid magic number). As I never dealt with
solaris partitions under Linux, I mind if something was changed in
Solaris10 or if there is a bug in the ufs driver.

OS is 2.6.12-1.1400_FC5 recompiled (ntfs/ufs/etc).

Best regards,

Casimiro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/2015a576/attachment.sig>

From dcbw at redhat.com  Tue Jul  5 13:33:04 2005
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 05 Jul 2005 09:33:04 -0400
Subject: Build system - how to ?
In-Reply-To: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>
References: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>
Message-ID: <1120570384.15277.4.camel@dcbw.boston.redhat.com>

On Mon, 2005-07-04 at 19:03 -0400, TGS wrote:
> Where can I find information on the build system for Fedora?

The build system for Fedora _Core_ is called beehive, and is internal to
Red Hat.  It's not publicly available, nor would it likely be all that
useful to the average package builder.

The build system for Fedora _Extras_, where more and more packages are
migrating to, is described at this page:

http://www.fedoraproject.org/wiki/Extras

New build system infrastructure for Extras is coming along which, when
python stops segfaulting with m2crypto & threads, will hopefully ease
the Extras package build process quite a bit.

Dan



From jjneely at pams.ncsu.edu  Tue Jul  5 14:23:33 2005
From: jjneely at pams.ncsu.edu (Jack Neely)
Date: Tue, 5 Jul 2005 10:23:33 -0400
Subject: Packaging kernel modules
In-Reply-To: <4820AB25719EA12BF80DD8DC@[10.169.6.233]>
References: <4820AB25719EA12BF80DD8DC@[10.169.6.233]>
Message-ID: <20050705142333.GH1972@anduril.pams.ncsu.edu>

On Wed, Jun 29, 2005 at 09:23:19PM -0700, Kenneth Porter wrote:
> I'm figuring out how to install nosy, a Firewire sniffer, and it involves 
> installing a kernel module. I'd like to wrap up what I learn in an RPM. 
> I've packaged apps before but not kernel modules. Can anyone point me to an 
> example that shows the preferred way to do it? The Makefile is already set 
> up for building outside the kernel tree, and accepts a prefix for /usr. 
> Will that work fine for building within an RPM_BUILD_ROOT? (Ie. does the 
> kernel build system tolerate logical installation directories?) Do I invoke 
> depmod in %post as I would ldconfig when installing a userspace library?
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

Being able to handle kernel modules is something that folks are currently
working on.  You might want to take a look at the archives of the
fedora-packaging list.

Jack

-- 
Jack Neely <slack at quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89



From ivazquez at ivazquez.net  Tue Jul  5 14:37:57 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 10:37:57 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120546013.6657.253.camel@mccallum.corsepiu.local>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120546013.6657.253.camel@mccallum.corsepiu.local>
Message-ID: <1120574278.15363.46.camel@ignacio.ignacio.lan>

On Tue, 2005-07-05 at 08:46 +0200, Ralf Corsepius wrote:
> On Tue, 2005-07-05 at 01:28 -0400, Ignacio Vazquez-Abrams wrote:
> > I'm currently trying to build a cross-compiler toolchain for mipsel
> > based on the packages in FC4, and I'm getting the following message when
> > running configure for gcc:
> > 
> > /usr/mipsel-linux/bin/as: symbol lookup error: /usr/mipsel-linux/bin/as:
> > undefined symbol: bfd_mips16_num_opcodes
> Wild guess (Without having tried to build your packages):
> 
> Your binutils seem to be dynamically linked against libbfd.
> At runtime you therefore get the libbfd as being shipped by FC, not the
> version having been built as part of your toolchain built.

Yep, that was it, thanks.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/af7cef52/attachment.sig>

From martin at bugs.unl.edu.ar  Tue Jul  5 14:46:55 2005
From: martin at bugs.unl.edu.ar (=?iso-8859-1?q?Mart=EDn_Marqu=E9s?=)
Date: Tue, 5 Jul 2005 11:46:55 -0300
Subject: SPARC
Message-ID: <200507051146.55666.martin@bugs.unl.edu.ar>

Is someone working on a SPARC port of Fedora Core?

-- 
 11:45:58 up 2 days, 20:31,  2 users,  load average: 1.40, 0.96, 0.56
-----------------------------------------------------------------
Lic. Mart?n Marqu?s   | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica  |  DBA, Programador, Administrador
             Universidad Nacional
                  del Litoral
-----------------------------------------------------------------



From thebs413 at earthlink.net  Tue Jul  5 15:05:12 2005
From: thebs413 at earthlink.net (Bryan J. Smith <b.j.smith@ieee.org>)
Date: Tue, 5 Jul 2005 10:05:12 -0500 (GMT-05:00)
Subject: e: Fedora Core 5 Idea -- let's drop this ...
Message-ID: <28922695.1120575913116.JavaMail.root@wamui-cypress.atl.sa.earthlink.net>

Sean wrote:  
> Huh?  You're reading something between the lines that just isn't there. 

Dude, don't even go there.  You have continually been making statements
like:  

  "We _really_ need people who care about open source to stop
   spreading the notion that there is no alternative to nVidia."

You have been doing it for _weeks_ now.  You have singlehandedly made
it about *1* company, which is _just_as_bad_ as the original requestors.
That's been my _sole_point_.

Damn me for previously actually explaining why nVidia is the only
solution for _some_ people.  I _never_ said there is "no alternative,"
and I am definitely _not_ a nVidia "cheerleader."  But for some people,
they can and will use nVidia, as well as ATI's proprietary source drivers,
as well as Matrox's proprietary source drivers, etc...

You have continued to _demonize_ things, and in many cases, interject
_false_ technical information, along with a few, select others.  This is
the problem with most "agendas," they tend to go past fact and into
false assumptions for political reasons, not technical reality.

That's the _only_ "problem" I've had.

> Anyway, let's do as Rahul asked before your first post on this thread,
> and let it go.

Actually, I was the one that use the phrase "let it go," shortly after
Rahul's.  I futher refined that into coming up with a standard response
with Rahul most excellently delivered, and I think that does the job.

Now I don't have any "weight" here, and I don't assume to have any
either.  But I've seen other people who aren't exactly "contributors"
throwing their weight, history and other credentials around, and
doing it a way that I would consider borderline "bigotry" (and
depending on how far people have been "explaining" things, some
might even qualify as "libel" but I doubt nVidia cares at this point)
on holding nVidia to one standard, but other companies to another.

And that would include yourself -- very much so -- because you have
singlehandedly associated "proprietary" with _only_ nVidia, and even
gone so far to stretch the notion to blame even ATI's moves on nVidia,
when the reasons were quite different.  ATI closed up the specifications
for many reasons (several of my good colleagues that I used to work
with in the semiconductor industry are now at ATI).

I think Rahul hit-it-on-the-nose with his post:  
> Would people stop discussing merits and demerits of particular
> brands of video cards and their drivers and market share in the
> Fedora development list. This is definitely off topic for this list.
> Kindly stop

Now at what point do you concede you are one of the biggest
hypocrites with regards to this response to me, given the context
I, Rahul and others have made?

Oh, nevermind, I forgot I was an nVidia cheerleader, so I might be
one of the people that are hurting open source.

Bigotry starts with labeling and intolerance driven by an agenda.
Again, I am so damn sorry I tried to explain things earlier from a
"middle ground," all while saying the Fedora Project should _never_
support proprietary source drivers, I have _never_ said otherwise.

You, however, seem to be solely fixated on nVidia.  While you
might claim that is the issue, because of your frustration with
others who buy nVidia's product and use nVidia's drivers while
seeking support here, it does _not_ mean you can blame nVidia
for it all, and make statements that just are _not_ true.  Be
objective, be considerate and stop the "reverse agenda," because
you too are making very vendor-blind statements.  ;->

And don't assume we all use nVidia's drivers, or only buy nVidia
products.  I only use their products+drivers if I absolutely need
them for an applpication today, and cannot wait 3-5 years.  And
_no_, it is _not_ for gaming.  Otherwise I typically go with Intel,
rewarding them for their efforts, or just use the MIT X11 "nv"
driver with the UtahGLX for older nVidia products that work well
enough.



--
Bryan J. Smith   mailto:b.j.smith at ieee.org



From alex.kiernan at gmail.com  Tue Jul  5 15:10:27 2005
From: alex.kiernan at gmail.com (Alex Kiernan)
Date: Tue, 5 Jul 2005 16:10:27 +0100
Subject: Is there a bug in UFS system (ufs=sunx86)
In-Reply-To: <42CA8444.5050204@gmail.com>
References: <42CA8444.5050204@gmail.com>
Message-ID: <c461c0d105070508103457b5a8@mail.gmail.com>

On 7/5/05, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> wrote:
> Hello,
> 
> Last week I had to install a Solaris 10 partition in a developent
> workstation. Whenever I try to mount the solaris partition:
> 
> /dev/hdd1          /Solaris               ufs
> ufs=sunx86,ro    0  0
  ^^^

Have you tried with is as ufstype?

-- 
Alex Kiernan



From dcbw at redhat.com  Tue Jul  5 15:15:39 2005
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 05 Jul 2005 11:15:39 -0400
Subject: SPARC
In-Reply-To: <200507051146.55666.martin@bugs.unl.edu.ar>
References: <200507051146.55666.martin@bugs.unl.edu.ar>
Message-ID: <1120576539.15277.11.camel@dcbw.boston.redhat.com>

On Tue, 2005-07-05 at 11:46 -0300, Mart?n Marqu?s wrote:
> Is someone working on a SPARC port of Fedora Core?

Yes, a number of people are.

http://www.auroralinux.org

The current build is called "Corona" and is based off of FC3.  There's
no bootable media yet for Corona, so you'll have to install Aurora 1.0
(RH 7.3 based) and yum upgrade to Corona, but I've done a bunch of those
and there's some helpful FAQs out there.  Search for "aurora linux
corona upgrade" on google.

http://www.kroptech.com/aurora-tangerine-upgrade-howto.html

Dan



From seanlkml at sympatico.ca  Tue Jul  5 15:16:01 2005
From: seanlkml at sympatico.ca (Sean)
Date: Tue, 5 Jul 2005 11:16:01 -0400 (EDT)
Subject: e: Fedora Core 5 Idea -- let's drop this ...
In-Reply-To: <28922695.1120575913116.JavaMail.root@wamui-cypress.atl.sa.earthlink.n
	et>
References: <28922695.1120575913116.JavaMail.root@wamui-cypress.atl.sa.earthlink.net>
Message-ID: <3929.10.10.10.24.1120576561.squirrel@linux1>

On Tue, July 5, 2005 11:05 am, Bryan J. Smith <b.j.smith at ieee.org> said:
> Sean wrote:
>> Huh?  You're reading something between the lines that just isn't there.
>
> Dude, don't even go there.  You have continually been making statements
> like:
>
>   "We _really_ need people who care about open source to stop
>    spreading the notion that there is no alternative to nVidia."
>
> You have been doing it for _weeks_ now.  You have singlehandedly made
> it about *1* company, which is _just_as_bad_ as the original requestors.
> That's been my _sole_point_.

You're just wrong.   The simple fact is that if you want to use open
source drivers there are better options than those provided by nVidia.  
If nVidia sold a card that was well supported by open source drivers, i'd
become their biggest supporter.

>
> Damn me for previously actually explaining why nVidia is the only
> solution for _some_ people.  I _never_ said there is "no alternative,"
> and I am definitely _not_ a nVidia "cheerleader."  But for some people,
> they can and will use nVidia, as well as ATI's proprietary source drivers,
> as well as Matrox's proprietary source drivers, etc...
>
> You have continued to _demonize_ things, and in many cases, interject
> _false_ technical information, along with a few, select others.  This is
> the problem with most "agendas," they tend to go past fact and into
> false assumptions for political reasons, not technical reality.
>
> That's the _only_ "problem" I've had.

No, the problem you've had is in failing to recognize that the brand
doesn't matter.   All i'm saying is buy the best card you can that runs
open source drivers.   You haven't said once that nVidia open source
drivers are superior to other offerings.  That's because cards from other
vendors have _better_ open source drivers.   Please try to understand this
once and for all so we can stop this thread.

> Actually, I was the one that use the phrase "let it go," shortly after
> Rahul's.  I futher refined that into coming up with a standard response
> with Rahul most excellently delivered, and I think that does the job.

What you want is the last word.  You should have just let it die when
Rahul asked it to die.

>
> Now I don't have any "weight" here, and I don't assume to have any
> either.  But I've seen other people who aren't exactly "contributors"
> throwing their weight, history and other credentials around, and
> doing it a way that I would consider borderline "bigotry" (and
> depending on how far people have been "explaining" things, some
> might even qualify as "libel" but I doubt nVidia cares at this point)
> on holding nVidia to one standard, but other companies to another.
>
> And that would include yourself -- very much so -- because you have
> singlehandedly associated "proprietary" with _only_ nVidia, and even
> gone so far to stretch the notion to blame even ATI's moves on nVidia,
> when the reasons were quite different.  ATI closed up the specifications
> for many reasons (several of my good colleagues that I used to work
> with in the semiconductor industry are now at ATI).

Wrong again.   I'm just dealing with the reality that the best open source
supported cards don't come from nVidia today.   I'd be just as happy as
anyone else if that changed.

> I think Rahul hit-it-on-the-nose with his post:
>> Would people stop discussing merits and demerits of particular
>> brands of video cards and their drivers and market share in the
>> Fedora development list. This is definitely off topic for this list.
>> Kindly stop
>
> Now at what point do you concede you are one of the biggest
> hypocrites with regards to this response to me, given the context
> I, Rahul and others have made?
>
> Oh, nevermind, I forgot I was an nVidia cheerleader, so I might be
> one of the people that are hurting open source.
>
> Bigotry starts with labeling and intolerance driven by an agenda.
> Again, I am so damn sorry I tried to explain things earlier from a
> "middle ground," all while saying the Fedora Project should _never_
> support proprietary source drivers, I have _never_ said otherwise.

You've been decidedly intolerant of anyone who stands up and says, use
open source solutions instead of binary only solutions.   All you hear is
an attack on nVidia instead of a support for open source solutions.  
There are some very good graphic cards available today that are supported
by open source.   Unfortunately they don't come from your favorite
supplier.

>
> You, however, seem to be solely fixated on nVidia.  While you
> might claim that is the issue, because of your frustration with
> others who buy nVidia's product and use nVidia's drivers while
> seeking support here, it does _not_ mean you can blame nVidia
> for it all, and make statements that just are _not_ true.  Be
> objective, be considerate and stop the "reverse agenda," because
> you too are making very vedor-blind statements.  ;->
>

That's because it is only nVidia cheerleaders who are constantly telling
people (usually without reservation or caution) to embrace binary only
drivers.   If more of you would tone down your support for binary only
solutions, you might get a different reaction.


> And don't assume we all use nVidia's drivers, or only buy nVidia
> products.  I only use their products+drivers if I absolutely need
> them for an applpication today, and cannot wait 3-5 years.  And
> _no_, it is _not_ for gaming.  Otherwise I typically go with Intel,
> rewarding them for their efforts, or just use the MIT X11 "nv"
> driver with the UtahGLX for older nVidia products that work well
> enough.
>

Well i'm glad to hear that;  you should really spend more time telling
people that open source solutions are preferable because you seem to spend
way more energy justifying binary drivers.

Cheers,
Sean




From martin at bugs.unl.edu.ar  Tue Jul  5 15:15:24 2005
From: martin at bugs.unl.edu.ar (=?utf-8?q?Mart=C3=ADn_Marqu=C3=A9s?=)
Date: Tue, 5 Jul 2005 12:15:24 -0300
Subject: SPARC
In-Reply-To: <200507051752.13781.cristian.balint@oradea.rdsnet.ro>
References: <200507051146.55666.martin@bugs.unl.edu.ar>
	<200507051752.13781.cristian.balint@oradea.rdsnet.ro>
Message-ID: <200507051215.25977.martin@bugs.unl.edu.ar>

El Mar 05 Jul 2005 11:52, escribi?:
> On Tuesday 05 July 2005 17:46, Mart?n Marqu?s wrote:
> > Is someone working on a SPARC port of Fedora Core?
> 
> http://www.auroralinux.org
> 
> There will find the community who works to port fedora on sparc/sparc64.

I know about Aurora Linux, but it's kind of dead.

-- 
 12:14:25 up 2 days, 21:00,  2 users,  load average: 1.55, 1.18, 0.92
-----------------------------------------------------------------
Lic. Mart?n Marqu?s   | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica  |  DBA, Programador, Administrador
             Universidad Nacional
                  del Litoral
-----------------------------------------------------------------



From dcbw at redhat.com  Tue Jul  5 15:36:33 2005
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 05 Jul 2005 11:36:33 -0400
Subject: SPARC
In-Reply-To: <200507051215.25977.martin@bugs.unl.edu.ar>
References: <200507051146.55666.martin@bugs.unl.edu.ar>
	<200507051752.13781.cristian.balint@oradea.rdsnet.ro>
	<200507051215.25977.martin@bugs.unl.edu.ar>
Message-ID: <1120577793.15277.16.camel@dcbw.boston.redhat.com>

On Tue, 2005-07-05 at 12:15 -0300, Mart?n Marqu?s wrote:
> El Mar 05 Jul 2005 11:52, escribi?:
> > On Tuesday 05 July 2005 17:46, Mart?n Marqu?s wrote:
> > > Is someone working on a SPARC port of Fedora Core?
> > 
> > http://www.auroralinux.org
> > 
> > There will find the community who works to port fedora on sparc/sparc64.
> 
> I know about Aurora Linux, but it's kind of dead.

Not at all, quite the opposite.  While the mailing lists aren't
high-traffic, there are usually a couple of messages per day on the user
mailing list, and Spot is tirelessly building packages.  We're about to
get a build cluster set up here in Westford to help Spot out, and Peter
Jones is fixing up Anaconda to get some bootable media for Corona.  It's
still quite alive and even more active than it was 6 - 8 months ago.

Dan



From vonbrand at inf.utfsm.cl  Tue Jul  5 15:52:16 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Tue, 05 Jul 2005 11:52:16 -0400
Subject: SPARC 
In-Reply-To: Your message of "Tue, 05 Jul 2005 11:36:33 -0400."
	<1120577793.15277.16.camel@dcbw.boston.redhat.com> 
Message-ID: <200507051552.j65FqGrv003332@laptop11.inf.utfsm.cl>

Dan Williams <dcbw at redhat.com> wrote:
> On Tue, 2005-07-05 at 12:15 -0300, Mart??n Marqu??s wrote:
> > El Mar 05 Jul 2005 11:52, escribi??:
> > > On Tuesday 05 July 2005 17:46, Mart??n Marqu??s wrote:
> > > > Is someone working on a SPARC port of Fedora Core?
> > > 
> > > http://www.auroralinux.org
> > > 
> > > There will find the community who works to port fedora on sparc/sparc64.
> > 
> > I know about Aurora Linux, but it's kind of dead.

> Not at all, quite the opposite.  While the mailing lists aren't
> high-traffic, there are usually a couple of messages per day on the user
> mailing list, and Spot is tirelessly building packages.  We're about to
> get a build cluster set up here in Westford to help Spot out, and Peter
> Jones is fixing up Anaconda to get some bootable media for Corona.  It's
> still quite alive and even more active than it was 6 - 8 months ago.

My mirroring hasn't picked up anything new for months now... perhaps I'm
pulling the wrong stuff?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From thebs413 at earthlink.net  Tue Jul  5 16:24:34 2005
From: thebs413 at earthlink.net (Bryan J. Smith <b.j.smith@ieee.org>)
Date: Tue, 5 Jul 2005 11:24:34 -0500 (GMT-05:00)
Subject: Fedora Core 5 Idea -- let's drop this ...
Message-ID: <10115336.1120580674568.JavaMail.root@wamui-cypress.atl.sa.earthlink.net>

From: Sean <seanlkml at sympatico.ca>
> You're just wrong.   The simple fact is that if you want to use open
> source drivers there are better options than those provided by nVidia.  

And better than ATI, than Matrox, etc...  I can play the game of
DRI/UtahGLX support for NV0x/NV1x (nVidia TNT-GeForce2) too.
I think people like yourself don't stop to realize they are applying 
"double standards."

I can also "play the game" of nVidia's better MIT X11 "nv" support than
ATI's MIT X11 "radeon" support when it comes to 2D, especially
regarding video in/video out (VIVO) support.

So at what point do you actually stop to recognize that not many
vendors are really supporting "open source" other than maybe Intel
(possibly 3DLabs?  I haven't checked) and that's _more_ than just
nVidia?

This is why _you_ are fixated on branding, _not_ me.

> No, the problem you've had is in failing to recognize that the brand
> doesn't matter.

Excuse me?  That's _exactly_ what I have been saying and you have
not.

> All i'm saying is buy the best card you can that runs open source
> drivers.


> You haven't said once that nVidia open source drivers are superior to
> other offerings.

I have not made _any_ claims, other than the fact that demonizing anyone
who uses nVidia's Standardware (open standard, proprietary source) is
a double-standard compared to ATI, Matrox and other companies.
Especially companies like Matrox, who's DRI/UtahGLX drivers are for the
same generation as those for nVidia's DRI/UtahGLX support (circa 2000-
2001), and _not_ newer either.

ATI went a bit longer, through the R200 series (circa 2002-2003), before
closing up the specs.  And as someone else pointed out, it wasn't ATI
who necessarily "supported" open source, other than releasing _some_
specifications.

Which leaves little more than Intel (I have not checked 3DLabs personally).
I'll not only applaud Intel, but I'll even buy their products when I just need
minimal GLX support.  But the performance and features are very sub-par,
even on the i9xx series -- not enough to run many CAM/EDA application.

But I neither advocated, nor will ever advocate use nVidia over other
vendors for general usage.  I stayed clear out of the threads _until_ it
reached a point where there were assumptions, half-truths and other
non-sense -- such as the junk you are throwing around.  You do _not_
fight a marketing agenda with another marketing agenda, especially
one that is _not_ factual.  That's has _always_ been my "problem."

> That's because cards from other vendors have _better_ open source
> drivers.

To what point?  I have some NV0x/NV1x cards with UtahGLX that do
some things.  I have some Intel cards.  I even have a few ATI R200
series.  On many I use the available, open source GLX.  On many
others, I don't even bother with GLX, and just use the MIT 2D.

No issues/arguments there.

But when I have a CAM/EDA application that doesn't run on those
lesser GLX solutions, I'm left with 4 options -- each of which may
or may not be available:  
1.  Use ATI and/or nVidia's Standardware drivers
2.  Use a 3rd party GLX product like X/Accelerated
3.  Use a non-Linux POSIX/GLX platform like Irix, Solaris, etc...
4.  Use the Win32/DirectX port if the vendor has one

According to you, I should be chastized for going with #1, along with
ATI and nVidia for supporting this marketing when they have absolutely
no legal way to do it with open source.  That's _all_ I've ever said!

> Please try to understand this once and for all so we can stop this
> thread.

If you haven't noticed, you're keeping this thread going on right along
with me.

> What you want is the last word.

Oh, don't even try to be that hypocritical.

> You should have just let it die when Rahul asked it to die.

You're right, I should have.  And maybe you should consider the same?

But no, you have repeatedly stated *1* company name based on your
assumptions and half-truths.  *1* company over and over.  You are
_no_better_ than the people who expect the Fedora Project to support
nVidia (let alone ATI, Matrox, etc...) Standardware drivers.

> Wrong again.   I'm just dealing with the reality that the best open
> source supported cards don't come from nVidia today.   I'd be just
> as happy as anyone else if that changed.

You are fixated on nVidia, get over it.  You keep asserting things
that are _not_ true, that's my problem as an engineer.

> You've been decidedly intolerant of anyone who stands up and says,
> use open source solutions instead of binary only solutions.

This is what I'm talking about, you continue to demonize _anyone_ who
even sees a use for the Standardware drivers.  All I _ever_ stated were
the reasons why people use the Standardware drivers, not that I
approve of them!

That's all!  When are you going to stop and recognize what I really said,
and not what agenda you think I am spreading (and trying to counter
with your own)?

> All you hear is an attack on nVidia instead of a support for open
> source solutions.  There are some very good graphic cards available
> today that are supported by open source.   Unfortunately they don't
> come from your favorite supplier.

Any chance you're going to stop demonizing whatever I say to what
fits you?

All I have ever said is that nVidia was the company that offered a
solution for CAM/EDA applications on Linux when _no_one_else_
would -- that's all!

I would _love_ to see Freedomware (Open Standard, Open Source)
drivers be able to viably drive many CAM/EDA applications on Linux.
And when I don't need that capability, I don't use such a solution.

Why you continue to paint me as a nVidia "cheerleader," I don't
know.  I guess you just want something to argue about.  In fact,
that's _exactly_ why I started responding to you in the first place,
because you were going around chatizing people as bad as others
complaining about lack of Fedora support.

Again, damn me for trying to explain a "middle ground."

> That's because it is only nVidia cheerleaders who are constantly
> telling people (usually without reservation or caution) to embrace
> binary only drivers.
> If more of you would tone down your support for binary only
> solutions, you might get a different reaction.

Please point out where I have ... and let's be explicit ...
  "constantly telling people (usually without reservation or caution)
   to embrace binary only drivers"

That's the "bigotry" and other non-sense I'm talking about!
You demonize some of our statements for the sake of arguing!

> Well i'm glad to hear that;

If you'd stop and actually _read_ what I say, instead of demonizing
what I say for the sake of arguing, maybe, just maybe you'd realize
what we are actually saying!

> you should really spend more time telling people that open source
> solutions are preferable because you seem to spend way more
> energy justifying binary drivers.

I do!  I have stated time and time again that people should not
only not expect the Fedora Project to support those Standardware
drivers, but that there is little reason to run with them for many
applications.  I haven't had to do much of that on this board,
people like Alan, Rahul, etc... have done an excellent job.

But I alos do it _across_the_board_ on _all_vendors_, not just get
fixated on 1.

That's where your "bigotry" comes in, and then you "demonize"
anyone who doesn't agree with your "vendor list" -- which seems
to be everyone but nVidia.  People ignore the previous XFree 3.3.x
releases, the UtahGLX work for NV0x/1x and the continued 2D
"nv" drivers.

Stop and listen to what I'm actually saying, not what you think I'm
saying or what agenda you think I'm pushing.  I don't prefer nVidia's
products for many applications, and I typically just stick with Intel's
integrated i8xx/i9xx solutions for the majority of non-engineering
desktops.

But when it comes to many CAM/EDA solutions, I have the option
of these 4:  
1.  Use ATI and/or nVidia's Standardware drivers
2.  Use a 3rd party GLX product like X/Accelerated
3.  Use a non-Linux POSIX/GLX platform like Irix, Solaris, etc...
4.  Use the Win32/DirectX port if the vendor has one

I don't see "open source" even listed there, so I can either choose
one of them, or just let a sale/integration go to another company
-- possibly with #3 or, quite often, #4.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org



From aoliva at redhat.com  Tue Jul  5 16:41:07 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 05 Jul 2005 13:41:07 -0300
Subject: Why are (unencrypted) DVD players forbidden?
In-Reply-To: <20050705054303.GA18908@nostromo.devel.redhat.com>
References: <20050704100557.2D428735AB@hormel.redhat.com>
	<1120494276.4569.24.camel@bert64.mobile.smithconcepts.com>
	<42C9635D.5080709@redhat.com>
	<orll4levds.fsf_-_@livre.redhat.lsd.ic.unicamp.br>
	<20050705054303.GA18908@nostromo.devel.redhat.com>
Message-ID: <orhdf9dx3w.fsf@livre.redhat.lsd.ic.unicamp.br>

On Jul  5, 2005, Bill Nottingham <notting at redhat.com> wrote:

> Alexandre Oliva (aoliva at redhat.com) said: 
>> So what's the excuse to not include such nice software as Ogle and
>> libdvdread (but not libdvdcss)?

> MPEG2 (and AC3, IIRC) are both patented. Which makes it pretty
> much a moot point.

Then the web page should say so, and not place all of the blame on the
DMCA.  [checks web page]  Cool, fixed :-)  Thanks!

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From martin at bugs.unl.edu.ar  Tue Jul  5 16:57:43 2005
From: martin at bugs.unl.edu.ar (=?iso-8859-1?q?Mart=EDn_Marqu=E9s?=)
Date: Tue, 5 Jul 2005 13:57:43 -0300
Subject: SPARC
In-Reply-To: <200507051552.j65FqGrv003332@laptop11.inf.utfsm.cl>
References: <200507051552.j65FqGrv003332@laptop11.inf.utfsm.cl>
Message-ID: <200507051357.44081.martin@bugs.unl.edu.ar>

El Mar 05 Jul 2005 12:52, Horst von Brand escribi?:
> Dan Williams <dcbw at redhat.com> wrote:
> 
> > Not at all, quite the opposite.  While the mailing lists aren't
> > high-traffic, there are usually a couple of messages per day on the user
> > mailing list, and Spot is tirelessly building packages.  We're about to
> > get a build cluster set up here in Westford to help Spot out, and Peter
> > Jones is fixing up Anaconda to get some bootable media for Corona.  It's
> > still quite alive and even more active than it was 6 - 8 months ago.
> 
> My mirroring hasn't picked up anything new for months now... perhaps I'm
> pulling the wrong stuff?

OK, I got a FC3 at home (AMD athlon), and at work we have 4 Ultra5, 1 Ultra10, 
and 1 Ultra1, all with Debian/SPARC, except the Ultra10 which has Solaris 7 
due to Informix.

Now, al thought I don't have the ability to use any of them, I can install 
what ever on my U5 workstation, but it shouldn't stop my programming (I can't 
have the WS down for a whole day).

Is there anything I can help with?

-- 
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
---------------------------------------------------------
Mart?n Marqu?s          |   Programador, DBA
Centro de Telem?tica	|     Administrador
               Universidad Nacional
                    del Litoral
---------------------------------------------------------



From dfarning at sbcglobal.net  Tue Jul  5 18:20:29 2005
From: dfarning at sbcglobal.net (david)
Date: Tue, 05 Jul 2005 13:20:29 -0500
Subject: Having a copy of .torrent in the /iso dir
Message-ID: <42CACF6D.8040203@sbcglobal.net>

I was just think that the fedora mirror system could save a little/a lot 
of bandwidth if there were copies of the .torrent files found at 
http://torrent.dulug.duke.edu/ in the /iso directories next to the 
actual iso files.  If these torrents were as convenient to get as the 
*.iso maybe more people would use them instead of just  saying 'what the 
heck' and clicking on the .iso.
Politically it would be a great statement.  One of the most significant 
open source companies stepping up and using bit torrent for an obviously 
legal purpose.  But, alas I'm not a lawyers so I have no idea the legal 
risks this would present.
-dtf



From mrsam at courier-mta.com  Tue Jul  5 19:00:47 2005
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Tue, 05 Jul 2005 15:00:47 -0400
Subject: Having a copy of .torrent in the /iso dir
References: <42CACF6D.8040203@sbcglobal.net>
Message-ID: <cone.1120590047.987686.28936.500@commodore.email-scan.com>

david writes:

> I was just think that the fedora mirror system could save a little/a lot 
> of bandwidth if there were copies of the .torrent files found at 
> http://torrent.dulug.duke.edu/ in the /iso directories next to the 
> actual iso files.  If these torrents were as convenient to get as the 
> *.iso maybe more people would use them instead of just  saying 'what the 
> heck' and clicking on the .iso.
> Politically it would be a great statement.  One of the most significant 
> open source companies stepping up and using bit torrent for an obviously 
> legal purpose.  But, alas I'm not a lawyers so I have no idea the legal 
> risks this would present.

There's absolutely no legal risk in publishing a .torrent of a Fedora iso.

It appears that torrents were set up independently by folks outside of 
Fedoraland-proper, and they've been managed this way all this time.

Although is comparatively little cost in publishing torrent content, but I 
think that having torrents published by an outside source is better.  When a 
new release comes out all the mirrors get hammered.  It would be nearly 
impossible for you to grab the torrent file then.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/15c10431/attachment.sig>

From ivazquez at ivazquez.net  Tue Jul  5 19:04:57 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 15:04:57 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120541334.15363.41.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
Message-ID: <1120590297.15363.53.camel@ignacio.ignacio.lan>

Okay, new problem.

stage1/xgcc -Bstage1/ -B/usr/mipsel-linux-elf/bin/   -O2 -g -pipe
-fexceptions -fasynchronous-unwind-tables
-I/usr/include/mipsel-linux-elf -I/usr/include
-L/usr/lib/mipsel-linux-elf -DIN_GCC -DCROSS_COMPILE  -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genmodes \
 build/genmodes.o
build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a
/usr/mipsel-linux-elf/bin/ld: ../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 3)
../build-i686-pc-linux-gnu/libiberty/libiberty.a: could not read
symbols: File in wrong format
collect2: ld returned 1 exit status

Once again the spec and log are in:

http://fedora.ivazquez.net/files/current/

How do I point it to /usr/lib/mipsel-linux-elf/libiberty.a instead, if
that's what's needed?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/59539d91/attachment.sig>

From sundaram at redhat.com  Tue Jul  5 19:07:05 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 06 Jul 2005 00:37:05 +0530
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <cone.1120590047.987686.28936.500@commodore.email-scan.com>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
Message-ID: <42CADA59.6050308@redhat.com>

Sam Varshavchik wrote:

> david writes:
>
>> I was just think that the fedora mirror system could save a little/a 
>> lot of bandwidth if there were copies of the .torrent files found at 
>> http://torrent.dulug.duke.edu/ in the /iso directories next to the 
>> actual iso files.  If these torrents were as convenient to get as the 
>> *.iso maybe more people would use them instead of just  saying 'what 
>> the heck' and clicking on the .iso.
>> Politically it would be a great statement.  One of the most 
>> significant open source companies stepping up and using bit torrent 
>> for an obviously legal purpose.  But, alas I'm not a lawyers so I 
>> have no idea the legal risks this would present.
>
>
> There's absolutely no legal risk in publishing a .torrent of a Fedora 
> iso.
>
> It appears that torrents were set up independently by folks outside of 
> Fedoraland-proper, and they've been managed this way all this time.

The torrent is setup by Seth Vidal, one of the primary developers of 
Yum, Fedora Extras management, Fedora Extras build system,  
Fedoraproject.org and so on. Sure he doesnt work for Red Hat but it is 
pretty much "Fedoraland" .

regards
Rahul



From casimiro.barreto at gmail.com  Tue Jul  5 19:11:41 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 05 Jul 2005 16:11:41 -0300
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <c461c0d105070508103457b5a8@mail.gmail.com>
References: <42CA8444.5050204@gmail.com>
	<c461c0d105070508103457b5a8@mail.gmail.com>
Message-ID: <42CADB6D.3050509@gmail.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/ea675b9e/attachment.htm>

From nmiell at comcast.net  Tue Jul  5 19:15:33 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Tue, 05 Jul 2005 12:15:33 -0700
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <cone.1120590047.987686.28936.500@commodore.email-scan.com>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
Message-ID: <1120590933.2944.17.camel@localhost.localdomain>

On Tue, 2005-07-05 at 15:00 -0400, Sam Varshavchik wrote:
> It appears that torrents were set up independently by folks outside of 
> Fedoraland-proper, and they've been managed this way all this time.
> 
> Although is comparatively little cost in publishing torrent content, but I 
> think that having torrents published by an outside source is better.  When a 
> new release comes out all the mirrors get hammered.  It would be nearly 
> impossible for you to grab the torrent file then.


The release method could be changed so that the only way to get a new
release via the first couple days is using BitTorrent. This would
probably eliminate the initial load spike that the mirrors get. If a few
of the mirrors can be convinced to seed the torrent, things would be
even nicer.

-- 
Nicholas Miell <nmiell at comcast.net>



From rjune at bravegnuworld.com  Tue Jul  5 19:54:04 2005
From: rjune at bravegnuworld.com (Richard June)
Date: Tue, 5 Jul 2005 14:54:04 -0500
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <1120590933.2944.17.camel@localhost.localdomain>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
Message-ID: <200507051454.08062.rjune@bravegnuworld.com>

I gotta say, I *LIKE* that plan.
you want fedora for the first few days, great. get the torrent.

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/fec5aecd/attachment.sig>

From pjones at redhat.com  Tue Jul  5 19:57:48 2005
From: pjones at redhat.com (Peter Jones)
Date: Tue, 05 Jul 2005 15:57:48 -0400
Subject: SPARC
In-Reply-To: <200507051552.j65FqGrv003332@laptop11.inf.utfsm.cl>
References: <200507051552.j65FqGrv003332@laptop11.inf.utfsm.cl>
Message-ID: <1120593468.3545.1.camel@localhost.localdomain>

On Tue, 2005-07-05 at 11:52 -0400, Horst von Brand wrote:

> My mirroring hasn't picked up anything new for months now... perhaps I'm
> pulling the wrong stuff?

Well, really the biggest stumbling block is Anaconda.  spot's done some
great work on it, and I spent some of last week debugging some parts he
felt uneasy with.  There's a little left to do before it's really
feasible to release a test of it, but we do hope to be there fairly
soon.
-- 
        Peter



From jspaleta at gmail.com  Tue Jul  5 20:28:17 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 5 Jul 2005 16:28:17 -0400
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <200507051454.08062.rjune@bravegnuworld.com>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
	<200507051454.08062.rjune@bravegnuworld.com>
Message-ID: <604aa79105070513282b6bb897@mail.gmail.com>

On 7/5/05, Richard June <rjune at bravegnuworld.com> wrote:
> I gotta say, I *LIKE* that plan.
> you want fedora for the first few days, great. get the torrent.

Thats very short sighted. Not everyone lives on a network that is
friendly to torrent activity.
I'm pretty sure that some of the official mirrors would much rather
see the users inside their local networks consume from a locally
available mirror than to waste bandwidth across the network boundary
to the outside world pulling from and pushing to torrent peers out in
the wild.  What exactly is the point of making life more difficult for
the admins of large networks who are volunteering to mirror fedora and
allow some public access? I very much doubt you would get all the
mirrors to agree to wait.  Even if by some miracle all those
'official' mirrors do wait... other people who get the torrent will
open mirrors regardless.
  
-jef



From nmiell at comcast.net  Tue Jul  5 20:37:27 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Tue, 05 Jul 2005 13:37:27 -0700
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <604aa79105070513282b6bb897@mail.gmail.com>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
	<200507051454.08062.rjune@bravegnuworld.com>
	<604aa79105070513282b6bb897@mail.gmail.com>
Message-ID: <1120595847.2944.32.camel@localhost.localdomain>

On Tue, 2005-07-05 at 16:28 -0400, Jeff Spaleta wrote:
> On 7/5/05, Richard June <rjune at bravegnuworld.com> wrote:
> > I gotta say, I *LIKE* that plan.
> > you want fedora for the first few days, great. get the torrent.
> 
> Thats very short sighted. Not everyone lives on a network that is
> friendly to torrent activity.

They can wait a week.

> I'm pretty sure that some of the official mirrors would much rather
> see the users inside their local networks consume from a locally
> available mirror than to waste bandwidth across the network boundary
> to the outside world pulling from and pushing to torrent peers out in
> the wild.

Those admins can set access controls on their FTP servers.

>  What exactly is the point of making life more difficult for
> the admins of large networks who are volunteering to mirror fedora and
> allow some public access? I very much doubt you would get all the
> mirrors to agree to wait. 

They wait already.

> Even if by some miracle all those
> 'official' mirrors do wait... other people who get the torrent will
> open mirrors regardless.

That's OK for them, the purpose of this exercise is to decrease the
stress on official mirrors, not prevent the propagation of Fedora.

-- 
Nicholas Miell <nmiell at comcast.net>



From ivazquez at ivazquez.net  Tue Jul  5 20:55:43 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 16:55:43 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120590297.15363.53.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120590297.15363.53.camel@ignacio.ignacio.lan>
Message-ID: <1120596943.15363.57.camel@ignacio.ignacio.lan>

On Tue, 2005-07-05 at 15:04 -0400, Ignacio Vazquez-Abrams wrote:
> Okay, new problem.

Never mind. Got it thanks to pinskia in #gcc.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/8f2ac3d4/attachment.sig>

From jspaleta at gmail.com  Tue Jul  5 21:02:49 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 5 Jul 2005 17:02:49 -0400
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <1120595847.2944.32.camel@localhost.localdomain>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
	<200507051454.08062.rjune@bravegnuworld.com>
	<604aa79105070513282b6bb897@mail.gmail.com>
	<1120595847.2944.32.camel@localhost.localdomain>
Message-ID: <604aa791050705140257e2a544@mail.gmail.com>

On 7/5/05, Nicholas Miell <nmiell at comcast.net> wrote:
> On Tue, 2005-07-05 at 16:28 -0400, Jeff Spaleta wrote:
> > On 7/5/05, Richard June <rjune at bravegnuworld.com> wrote:
> > > I gotta say, I *LIKE* that plan.
> > > you want fedora for the first few days, great. get the torrent.
> >
> > Thats very short sighted. Not everyone lives on a network that is
> > friendly to torrent activity.
> 
> They can wait a week.

But the won't wait. Just like the god damn morons who sneak out a
torrent from an unlocked mirrors don't wait.  As soon as its in the
wild in any way shape or form.. people are going to mirror it in a way
that works best for them.  That means rsync and ftp and http mirrors
will spring up as soon as possible to fill the need.  People CAN 
CHOOSE to use the torrent right now. People aren't CHOOSING to do
that. If the torrent was clearly the best option for the majority of
the userbase... we wouldn't see the mirrors being hammered on release
day.  I think people need to stop trying to force the torrent to be
the one-true  distribution technology.

> Those admins can set access controls on their FTP servers.

So its not really a staggered release then is it... if mirror admins
can individual choose to wait or not... you haven't really
accomplished much.

> They wait already.

> That's OK for them, the purpose of this exercise is to decrease the
> stress on official mirrors, not prevent the propagation of Fedora.

Or perhaps, it would just inspire official mirrors from delisting from
the official list in order to be free to open the tree for the segment
of the userbase they are most concerned with serving. How effective is
that torrent seed based in the US ... compared to a mirror in
australia.. if you are living in australia ... on that first day of
release or the second day of the release?  Hmmm?

If the purpose of this excercise is to decrease the stress on the
official mirrors.. how about we make sure the official mirrors like
the idea of waiting longer while a torrent opens up.  I'm pretty sure
the idea of a staggered release has come up before, and if it were a
concensous among those hosting official mirrors I'm pretty sure the
policy would be in place right now.

-jef



From nmiell at comcast.net  Tue Jul  5 21:11:51 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Tue, 05 Jul 2005 14:11:51 -0700
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <604aa791050705140257e2a544@mail.gmail.com>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
	<200507051454.08062.rjune@bravegnuworld.com>
	<604aa79105070513282b6bb897@mail.gmail.com>
	<1120595847.2944.32.camel@localhost.localdomain>
	<604aa791050705140257e2a544@mail.gmail.com>
Message-ID: <1120597911.2944.38.camel@localhost.localdomain>

On Tue, 2005-07-05 at 17:02 -0400, Jeff Spaleta wrote:
> On 7/5/05, Nicholas Miell <nmiell at comcast.net> wrote:
> > On Tue, 2005-07-05 at 16:28 -0400, Jeff Spaleta wrote:
> > > On 7/5/05, Richard June <rjune at bravegnuworld.com> wrote:
> > > > I gotta say, I *LIKE* that plan.
> > > > you want fedora for the first few days, great. get the torrent.
> > >
> > > Thats very short sighted. Not everyone lives on a network that is
> > > friendly to torrent activity.
> > 
> > They can wait a week.
> 
> But the won't wait. Just like the god damn morons who sneak out a
> torrent from an unlocked mirrors don't wait.  As soon as its in the
> wild in any way shape or form.. people are going to mirror it in a way
> that works best for them.  That means rsync and ftp and http mirrors
> will spring up as soon as possible to fill the need.  

Why is this bad?

> People CAN 
> CHOOSE to use the torrent right now. People aren't CHOOSING to do
> that. If the torrent was clearly the best option for the majority of
> the userbase... we wouldn't see the mirrors being hammered on release
> day.  I think people need to stop trying to force the torrent to be
> the one-true  distribution technology.

Perhaps they aren't using the torrent because they either don't know
about it or they are lazy.

> > Those admins can set access controls on their FTP servers.
> 
> So its not really a staggered release then is it... if mirror admins
> can individual choose to wait or not... you haven't really
> accomplished much.

A staggered release to the general public. If the admin at a .edu wants
to allow their institution access to their local mirror in order to cut
down on external bandwidth, there's no reason to stop them from doing so
after the official general BitTorrent release.

> > That's OK for them, the purpose of this exercise is to decrease the
> > stress on official mirrors, not prevent the propagation of Fedora.
> 
> Or perhaps, it would just inspire official mirrors from delisting from
> the official list in order to be free to open the tree for the segment
> of the userbase they are most concerned with serving. How effective is
> that torrent seed based in the US ... compared to a mirror in
> australia.. if you are living in australia ... on that first day of
> release or the second day of the release?  Hmmm?

.au allowing access to .au isn't much different from a .edu allowing
internal access.

-- 
Nicholas Miell <nmiell at comcast.net>



From jspaleta at gmail.com  Tue Jul  5 21:23:42 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 5 Jul 2005 17:23:42 -0400
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <1120597911.2944.38.camel@localhost.localdomain>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
	<200507051454.08062.rjune@bravegnuworld.com>
	<604aa79105070513282b6bb897@mail.gmail.com>
	<1120595847.2944.32.camel@localhost.localdomain>
	<604aa791050705140257e2a544@mail.gmail.com>
	<1120597911.2944.38.camel@localhost.localdomain>
Message-ID: <604aa79105070514232f698513@mail.gmail.com>

On 7/5/05, Nicholas Miell <nmiell at comcast.net> wrote:
> .au allowing access to .au isn't much different from a .edu allowing
> internal access.

Go on.. get the official mirror admins to agree to this sort of thing.
I dare you.

-jef



From bgerst at didntduck.org  Tue Jul  5 21:26:19 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Tue, 05 Jul 2005 17:26:19 -0400
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <604aa791050705140257e2a544@mail.gmail.com>
References: <42CACF6D.8040203@sbcglobal.net>	<cone.1120590047.987686.28936.500@commodore.email-scan.com>	<1120590933.2944.17.camel@localhost.localdomain>	<200507051454.08062.rjune@bravegnuworld.com>	<604aa79105070513282b6bb897@mail.gmail.com>	<1120595847.2944.32.camel@localhost.localdomain>
	<604aa791050705140257e2a544@mail.gmail.com>
Message-ID: <42CAFAFB.5090206@didntduck.org>

Jeff Spaleta wrote:
> On 7/5/05, Nicholas Miell <nmiell at comcast.net> wrote:
> 
>>On Tue, 2005-07-05 at 16:28 -0400, Jeff Spaleta wrote:
>>
>>>On 7/5/05, Richard June <rjune at bravegnuworld.com> wrote:
>>>
>>>>I gotta say, I *LIKE* that plan.
>>>>you want fedora for the first few days, great. get the torrent.
>>>
>>>Thats very short sighted. Not everyone lives on a network that is
>>>friendly to torrent activity.
>>
>>They can wait a week.
> 
> 
> But the won't wait. Just like the god damn morons who sneak out a
> torrent from an unlocked mirrors don't wait.  As soon as its in the
> wild in any way shape or form.. people are going to mirror it in a way
> that works best for them.  That means rsync and ftp and http mirrors
> will spring up as soon as possible to fill the need.  

If people set up their own mirrors it's their bandwidth, their problem. 
  Why do we care?

--
				Brian Gerst



From thebs413 at earthlink.net  Tue Jul  5 21:35:41 2005
From: thebs413 at earthlink.net (Bryan J. Smith <b.j.smith@ieee.org>)
Date: Tue, 5 Jul 2005 16:35:41 -0500 (GMT-05:00)
Subject: Apology for being a troll ...
Message-ID: <15483790.1120599342052.JavaMail.root@wamui-chisos.atl.sa.earthlink.net>

I don't know if I should waste the list's time any more than I have,
but I analyzed my responses in the two most previous threads on
nVidia, as well the software patent thread, and I have come to the
conclusion that regardless of what my initial posts might have been,
or what I had hoped to accomplish, I clearly broke down into more
of a "troll" in responding to a few individuals.  I want to apologize
for those comments -- especially the latter posts.

Those who know me know I can clearly break down into almost a
self-defeating person in e-mail.  I'm clearly much better at discussing
these details in person -- especially in a consulting or training
role, as well as in a formal, well-planned article or presentation.
For some reason the inpromptu rationale and choice of words
escapes me in e-mail, and I don't always handle responses the way
that would most effectively show my viewpoint.  I showed some
greatly poor examples in the last few weeks.

So my apology.  Again, I can honestly and with great humility admit
that well over half of my responses clearly fall into the "troll" type
of response, and I will be more attentive and objective will ensuring
any posts I make have more thought and to-the-point wit to them
in the future.  Your forgiveness for my recent transgressions is
greatly appreciated, and I'll keep them at the forefront of my mind
when contemplating any future response.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org



From jspaleta at gmail.com  Tue Jul  5 21:35:31 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 5 Jul 2005 17:35:31 -0400
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <604aa79105070514334e828826@mail.gmail.com>
References: <42CACF6D.8040203@sbcglobal.net>
	<cone.1120590047.987686.28936.500@commodore.email-scan.com>
	<1120590933.2944.17.camel@localhost.localdomain>
	<200507051454.08062.rjune@bravegnuworld.com>
	<604aa79105070513282b6bb897@mail.gmail.com>
	<1120595847.2944.32.camel@localhost.localdomain>
	<604aa791050705140257e2a544@mail.gmail.com>
	<42CAFAFB.5090206@didntduck.org>
	<604aa79105070514334e828826@mail.gmail.com>
Message-ID: <604aa791050705143560341474@mail.gmail.com>

On 7/5/05, Brian Gerst <bgerst at didntduck.org> wrote:
> If people set up their own mirrors it's their bandwidth, their problem.
>   Why do we care?

If those people end up being exactly the same admins who use to be
official mirrors....
Explain to me.. in very small words... from a mirror admin
perspective... why exactly they should choose to stagger their
release.. instead of just going rogue, grabbing a torrent and
producing a mirror from that and forsaking 'official' status?

You better make damn sure the official mirror admins are interested in
staggering, before you suggest it as a policy. Because if there is one
very good way of causing a worse mirroring bottleneck it is to have
mirrors choose to drop out of the official list.

-jef



From loony at loonybin.org  Tue Jul  5 21:42:25 2005
From: loony at loonybin.org (Peter Arremann)
Date: Tue, 5 Jul 2005 17:42:25 -0400
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <42CADB6D.3050509@gmail.com>
References: <42CA8444.5050204@gmail.com>
	<c461c0d105070508103457b5a8@mail.gmail.com>
	<42CADB6D.3050509@gmail.com>
Message-ID: <200507051742.25856.loony@loonybin.org>

On Tuesday 05 July 2005 15:11, Casimiro de Almeida Barreto wrote:
>  Excuses, I just wrote that wrong:
>
>  /dev/hdd1??? /Solaris????????? ufs????????? ufstype=sunx86,ro????? 0? 0
>
>  That's what I get:
>
>  [root at 200-185-243-180 casimiro]# !mount
>  mount -vat ufs
>  mount: wrong fs type, bad option, bad superblock on /dev/hdd1,
>  ?????? missing codepage or other error
>  ?????? In some cases useful info is found in syslog - try
>  ?????? dmesg | tail? or so
>
>  And then, with dmesg | tail:
>
>  [root at 200-185-243-180 casimiro]# dmesg | tail
>  parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
>  lp0: using parport0 (interrupt-driven).
>  lp0: console ready
>  application mozilla-bin uses obsolete OSS audio interface
>  application firefox-bin uses obsolete OSS audio interface
>  application mplayer uses obsolete OSS audio interface
>  application mozilla-bin uses obsolete OSS audio interface
>  application skype uses obsolete OSS audio interface
>  application firefox-bin uses obsolete OSS audio interface
>  ufs_read_super: bad magic number
>
>  So, it seems that something is wrong with ufs driver.
>
>  Regards,
>
>  Casimiro
Sorry if I missed it before but could you post the partition informiation 
listed by Linux at bootup? You have sun disklabel support compiled into the 
kernel, right?

Peter.



From ivazquez at ivazquez.net  Tue Jul  5 23:23:24 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 19:23:24 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120541334.15363.41.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
Message-ID: <1120605804.15363.62.camel@ignacio.ignacio.lan>

SO close...

+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation
error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)

http://fedora.ivazquez.net/files/current/

How can I tell rpmbuild to not strip those files, or to point it to the
proper strip?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/518ee45a/attachment.sig>

From casimiro.barreto at gmail.com  Tue Jul  5 23:52:14 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 05 Jul 2005 20:52:14 -0300
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <200507051742.25856.loony@loonybin.org>
References: <42CA8444.5050204@gmail.com>	<c461c0d105070508103457b5a8@mail.gmail.com>	<42CADB6D.3050509@gmail.com>
	<200507051742.25856.loony@loonybin.org>
Message-ID: <42CB1D2E.10700@gmail.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/45a7488b/attachment.htm>

From rc040203 at freenet.de  Tue Jul  5 23:54:09 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 06 Jul 2005 01:54:09 +0200
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120605804.15363.62.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120605804.15363.62.camel@ignacio.ignacio.lan>
Message-ID: <1120607649.30532.83.camel@mccallum.corsepiu.local>

On Tue, 2005-07-05 at 19:23 -0400, Ignacio Vazquez-Abrams wrote:
> SO close...
> 
> + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation
> /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation
> error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
> 
> http://fedora.ivazquez.net/files/current/
> 
> How can I tell rpmbuild to not strip those files, or to point it to the
> proper strip?

By redefining __os_install_post (cf. rpm --showrc) and/or by providing
your own brp-strip-static-archive (AFAICT, the "strip" is hard-coded
into /usr/lib/rpm/brp-strip-static-archive).

The brute-force way would be to disable __os_install_post:
%define __os_install_post       %{nil}

Ralf




From loony at loonybin.org  Wed Jul  6 00:10:24 2005
From: loony at loonybin.org (Peter Arremann)
Date: Tue, 5 Jul 2005 20:10:24 -0400
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <42CB1D2E.10700@gmail.com>
References: <42CA8444.5050204@gmail.com>
	<200507051742.25856.loony@loonybin.org> <42CB1D2E.10700@gmail.com>
Message-ID: <200507052010.24935.loony@loonybin.org>

On Tuesday 05 July 2005 19:52, Casimiro de Almeida Barreto wrote:
>  Yes, it was compiled with disklabel...
But what is the output the kernel makes for your drive /dev/hdd on bootup?

Peter.



From dfarning at sbcglobal.net  Wed Jul  6 00:14:04 2005
From: dfarning at sbcglobal.net (david)
Date: Tue, 05 Jul 2005 19:14:04 -0500
Subject: Having a copy of .torrent in the /iso dir
In-Reply-To: <604aa791050705143560341474@mail.gmail.com>
References: <42CACF6D.8040203@sbcglobal.net>	<cone.1120590047.987686.28936.500@commodore.email-scan.com>	<1120590933.2944.17.camel@localhost.localdomain>	<200507051454.08062.rjune@bravegnuworld.com>	<604aa79105070513282b6bb897@mail.gmail.com>	<1120595847.2944.32.camel@localhost.localdomain>	<604aa791050705140257e2a544@mail.gmail.com>	<42CAFAFB.5090206@didntduck.org>	<604aa79105070514334e828826@mail.gmail.com>
	<604aa791050705143560341474@mail.gmail.com>
Message-ID: <42CB224C.6080009@sbcglobal.net>

Jeff Spaleta wrote:

>On 7/5/05, Brian Gerst <bgerst at didntduck.org> wrote:
>  
>
>>If people set up their own mirrors it's their bandwidth, their problem.
>>  Why do we care?
>>    
>>
>
>If those people end up being exactly the same admins who use to be
>official mirrors....
>Explain to me.. in very small words... from a mirror admin
>perspective... why exactly they should choose to stagger their
>release.. instead of just going rogue, grabbing a torrent and
>producing a mirror from that and forsaking 'official' status?
>
>You better make damn sure the official mirror admins are interested in
>staggering, before you suggest it as a policy. Because if there is one
>very good way of causing a worse mirroring bottleneck it is to have
>mirrors choose to drop out of the official list.
>
>-jef
>
>  
>
Hey hold on here guys, I was _only_ suggesting that the .torrents be 
made available in what seems to be a more convenient location.  Like 
putting the low fat baked potato chips on the shelf next to the regular 
chips, not back in the health food section.  For whatever reason many 
will still grab the regular chips, but a few might grab the low fat version;
-dtf



From ivazquez at ivazquez.net  Wed Jul  6 00:38:16 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 20:38:16 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120607649.30532.83.camel@mccallum.corsepiu.local>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120605804.15363.62.camel@ignacio.ignacio.lan>
	<1120607649.30532.83.camel@mccallum.corsepiu.local>
Message-ID: <1120610296.15363.64.camel@ignacio.ignacio.lan>

On Wed, 2005-07-06 at 01:54 +0200, Ralf Corsepius wrote:
> On Tue, 2005-07-05 at 19:23 -0400, Ignacio Vazquez-Abrams wrote:
> > SO close...
> > 
> > + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation
> > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation
> > error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
> > 
> > http://fedora.ivazquez.net/files/current/
> > 
> > How can I tell rpmbuild to not strip those files, or to point it to the
> > proper strip?
> 
> By redefining __os_install_post (cf. rpm --showrc) and/or by providing
> your own brp-strip-static-archive (AFAICT, the "strip" is hard-coded
> into /usr/lib/rpm/brp-strip-static-archive).

I managed to figure it out thanks to some nudging in the right direction
from jbj.

FTR, you can define %__strip to change what you use to strip.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/3727b2ea/attachment.sig>

From rc040203 at freenet.de  Wed Jul  6 00:57:40 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 06 Jul 2005 02:57:40 +0200
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120610296.15363.64.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120605804.15363.62.camel@ignacio.ignacio.lan>
	<1120607649.30532.83.camel@mccallum.corsepiu.local>
	<1120610296.15363.64.camel@ignacio.ignacio.lan>
Message-ID: <1120611460.30532.86.camel@mccallum.corsepiu.local>

On Tue, 2005-07-05 at 20:38 -0400, Ignacio Vazquez-Abrams wrote:
> On Wed, 2005-07-06 at 01:54 +0200, Ralf Corsepius wrote:
> > On Tue, 2005-07-05 at 19:23 -0400, Ignacio Vazquez-Abrams wrote:
> > > SO close...
> > > 
> > > + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation
> > > /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation
> > > error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
> > > 
> > > http://fedora.ivazquez.net/files/current/
> > > 
> > > How can I tell rpmbuild to not strip those files, or to point it to the
> > > proper strip?
> > 
> > By redefining __os_install_post (cf. rpm --showrc) and/or by providing
> > your own brp-strip-static-archive (AFAICT, the "strip" is hard-coded
> > into /usr/lib/rpm/brp-strip-static-archive).
> 
> I managed to figure it out thanks to some nudging in the right direction
> from jbj.
> 
> FTR, you can define %__strip to change what you use to strip.

/usr/lib/rpm/brp-strip-static-archive has "strip" hard-coded into it:

> 
>        sed -n -e 's/^\(.*\):[  ]*current ar archive/\1/p'`; do
>        strip -g $f
>done

Ralf




From ivazquez at ivazquez.net  Wed Jul  6 01:15:54 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 21:15:54 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120611460.30532.86.camel@mccallum.corsepiu.local>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120605804.15363.62.camel@ignacio.ignacio.lan>
	<1120607649.30532.83.camel@mccallum.corsepiu.local>
	<1120610296.15363.64.camel@ignacio.ignacio.lan>
	<1120611460.30532.86.camel@mccallum.corsepiu.local>
Message-ID: <1120612554.15363.69.camel@ignacio.ignacio.lan>

On Wed, 2005-07-06 at 02:57 +0200, Ralf Corsepius wrote:
> On Tue, 2005-07-05 at 20:38 -0400, Ignacio Vazquez-Abrams wrote:
> > FTR, you can define %__strip to change what you use to strip.
> 
> /usr/lib/rpm/brp-strip-static-archive has "strip" hard-coded into it:
> 
> > 
> >        sed -n -e 's/^\(.*\):[  ]*current ar archive/\1/p'`; do
> >        strip -g $f
> >done

/usr/lib/rpm/redhat/brp-strip-static-archive takes the command as the
first argument:

> [ -z "$STRIP" -a -n "$1" ] && STRIP="$1"
> [ -z "$STRIP" ] && STRIP=strip
 ...
>         $STRIP -g $f

And in /usr/lib/rpm/redhat/macros:

> %__os_install_post    \
>     /usr/lib/rpm/redhat/brp-compress \
>     /usr/lib/rpm/redhat/brp-strip %{__strip} \
>     /usr/lib/rpm/redhat/brp-strip-static-archive %{__strip} \
>     /usr/lib/rpm/redhat/brp-strip-comment-note %{__strip} %{__objdump} \
> %{nil}

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/8ad2a4f9/attachment.sig>

From dfarning at sbcglobal.net  Wed Jul  6 01:20:38 2005
From: dfarning at sbcglobal.net (david)
Date: Tue, 05 Jul 2005 20:20:38 -0500
Subject: physical distances vs. net distances
Message-ID: <42CB31E6.605@sbcglobal.net>

Jeff's comment about grabbing from a local mirror got me thinking about 
distances to mirrors. So, I tried tracing the route to my local 
University of Wisconsin, Madison mirror about 5 Miles down the road in 
the Comp. Sci. building.  For some odd reason sbcglobal is routing that 
traffic through Chicago, Ill and back, about a 300 mile round trip.  
Pinging is fast and my dsl line to always maxed out.  There must be some 
bizarrely fat pipes between Madison and Chicago;  I might as well look 
for a mirror in Chicago.
-dtf



From ivazquez at ivazquez.net  Wed Jul  6 03:02:50 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 05 Jul 2005 23:02:50 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120541334.15363.41.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
Message-ID: <1120618970.15363.73.camel@ignacio.ignacio.lan>

Okay, *almost* there.

Which of these files are important?

   /usr/bin/stVv16b0
   /usr/bin/stdTtJd1
   /usr/bin/stnIJwI1
   /usr/bin/stxfFoJZ
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/gsyslimits.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/README
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/float.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/iso646.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/limits.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdarg.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdbool.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stddef.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/unwind.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/varargs.h
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/macro_list
   /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/mkheaders.conf
   /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fix-header
   /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixinc.sh
   /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixproto
   /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/stXW4r1X
   /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stb6V9S0
   /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stzwRUzZ
   /usr/libexec/getconf/default

http://fedora.ivazquez.net/files/current/

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050705/caa7781b/attachment.sig>

From subsolar at subsolar.com  Wed Jul  6 03:30:14 2005
From: subsolar at subsolar.com (Paul)
Date: Tue, 05 Jul 2005 22:30:14 -0500
Subject: physical distances vs. net distances
In-Reply-To: <42CB31E6.605@sbcglobal.net>
References: <42CB31E6.605@sbcglobal.net>
Message-ID: <1120620614.5801.7.camel@localhost>

On Tue, 2005-07-05 at 20:20 -0500, david wrote:
> Jeff's comment about grabbing from a local mirror got me thinking about 
> distances to mirrors. So, I tried tracing the route to my local 
> University of Wisconsin, Madison mirror about 5 Miles down the road in 
> the Comp. Sci. building.  For some odd reason sbcglobal is routing that 
> traffic through Chicago, Ill and back, about a 300 mile round trip.  
> Pinging is fast and my dsl line to always maxed out.  There must be some 
> bizarrely fat pipes between Madison and Chicago;  I might as well look 
> for a mirror in Chicago.
> -dtf

Similar situation here ... I've found that physical distance has little
to do with throughput.  Charter used to route traffic though NY/SF ... I
sometimes would get faster throughput by downloading from European or
Asian sites.  I still do use the UW Madison mirror since I figure my tax
dollars are paying for it and I should use it instead of somebody
else's.

Paul



From jkeating at j2solutions.net  Tue Jul  5 04:12:31 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 04 Jul 2005 21:12:31 -0700
Subject: physical distances vs. net distances
In-Reply-To: <1120620614.5801.7.camel@localhost>
References: <42CB31E6.605@sbcglobal.net> <1120620614.5801.7.camel@localhost>
Message-ID: <1120536751.3895.8.camel@yoda.loki.me>

On Tue, 2005-07-05 at 22:30 -0500, Paul wrote:
> > Jeff's comment about grabbing from a local mirror got me thinking
> about 
> > distances to mirrors. So, I tried tracing the route to my local 
> > University of Wisconsin, Madison mirror about 5 Miles down the road
> in 
> > the Comp. Sci. building.  For some odd reason sbcglobal is routing
> that 
> > traffic through Chicago, Ill and back, about a 300 mile round
> trip.  
> > Pinging is fast and my dsl line to always maxed out.  There must be
> some 
> > bizarrely fat pipes between Madison and Chicago;  I might as well
> look 
> > for a mirror in Chicago.
> > -dtf
> 
> Similar situation here ... I've found that physical distance has
> little
> to do with throughput.  Charter used to route traffic though NY/SF ...
> I
> sometimes would get faster throughput by downloading from European or
> Asian sites.  I still do use the UW Madison mirror since I figure my
> tax
> dollars are paying for it and I should use it instead of somebody
> else's.
> 

For the most part, intra-continental routing has little difference to
your download speed, unless it is something like Alaska to Florida or
Seattle to New York type thing.  Usually very very high bandwidth lines
are used in such long jumps before breaking down into lower bandwidth
and dispersing out over an area.  However INTER-continental traffic has
to go under the pond if you will and there is a lot of latency (and
cost) there.  This is why using a mirror in your country or continent
will be much more preferred than crossing an ocean to get your files.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From spam at tachegroup.com  Wed Jul  6 05:15:23 2005
From: spam at tachegroup.com (TGS)
Date: Wed, 6 Jul 2005 01:15:23 -0400
Subject: Build system - how to ?
In-Reply-To: <1120570384.15277.4.camel@dcbw.boston.redhat.com>
References: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>
	<1120570384.15277.4.camel@dcbw.boston.redhat.com>
Message-ID: <3c8c9c78b23d8fe2b09b930976469cac@tachegroup.com>

Thanks for the link on Fedora Extras.

As far as Fedora Core is concerned, does that mean that no body can 
see, understand, or even reproduce the Fedora Core build process, 
beehive? That does not seem too Open Source to me.


On Jul 5, 2005, at 9:33 AM, Dan Williams wrote:

> On Mon, 2005-07-04 at 19:03 -0400, TGS wrote:
>> Where can I find information on the build system for Fedora?
>
> The build system for Fedora _Core_ is called beehive, and is internal 
> to
> Red Hat.  It's not publicly available, nor would it likely be all that
> useful to the average package builder.
>
> The build system for Fedora _Extras_, where more and more packages are
> migrating to, is described at this page:
>
> http://www.fedoraproject.org/wiki/Extras
>
> New build system infrastructure for Extras is coming along which, when
> python stops segfaulting with m2crypto & threads, will hopefully ease
> the Extras package build process quite a bit.
>
> Dan
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jkeating at j2solutions.net  Tue Jul  5 05:19:53 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 04 Jul 2005 22:19:53 -0700
Subject: Build system - how to ?
In-Reply-To: <3c8c9c78b23d8fe2b09b930976469cac@tachegroup.com>
References: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>
	<1120570384.15277.4.camel@dcbw.boston.redhat.com>
	<3c8c9c78b23d8fe2b09b930976469cac@tachegroup.com>
Message-ID: <1120540793.3895.14.camel@yoda.loki.me>

On Wed, 2005-07-06 at 01:15 -0400, TGS wrote:
> Thanks for the link on Fedora Extras.
> 
> As far as Fedora Core is concerned, does that mean that no body can 
> see, understand, or even reproduce the Fedora Core build process, 
> beehive? That does not seem too Open Source to me.

Please see list archives for many conversations on this topic.

Gist:  Fedora Core uses the Red Hat Enterprise Build system for lack of
anything else right now.  Work is being done on Fedora Extras build
system which may eventually be used to build Fedora Core.  Beehive
cannot be opened at this time due to things outside the control of the
Fedora Project.  Time would be much better spent working on new build
system than hashing out whether or not it is Open Source or GPL
compliant to have the beehive open for review.  Beehive is really just a
scheduling layer for rpmbuild so you can just use rpm build and anaconda
tools to build your own Fedora.  End of topic.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From spam at tachegroup.com  Wed Jul  6 05:53:23 2005
From: spam at tachegroup.com (TGS)
Date: Wed, 6 Jul 2005 01:53:23 -0400
Subject: Build system - how to ?
In-Reply-To: <1120540793.3895.14.camel@yoda.loki.me>
References: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>
	<1120570384.15277.4.camel@dcbw.boston.redhat.com>
	<3c8c9c78b23d8fe2b09b930976469cac@tachegroup.com>
	<1120540793.3895.14.camel@yoda.loki.me>
Message-ID: <8b59e762cd78dbb3c2eba765ea4a1391@tachegroup.com>

Okay, I will look at the archives.

On Jul 5, 2005, at 1:19 AM, Jesse Keating wrote:

> On Wed, 2005-07-06 at 01:15 -0400, TGS wrote:
>> Thanks for the link on Fedora Extras.
>>
>> As far as Fedora Core is concerned, does that mean that no body can
>> see, understand, or even reproduce the Fedora Core build process,
>> beehive? That does not seem too Open Source to me.
>
> Please see list archives for many conversations on this topic.
>
> Gist:  Fedora Core uses the Red Hat Enterprise Build system for lack of
> anything else right now.  Work is being done on Fedora Extras build
> system which may eventually be used to build Fedora Core.  Beehive
> cannot be opened at this time due to things outside the control of the
> Fedora Project.  Time would be much better spent working on new build
> system than hashing out whether or not it is Open Source or GPL
> compliant to have the beehive open for review.  Beehive is really just 
> a
> scheduling layer for rpmbuild so you can just use rpm build and 
> anaconda
> tools to build your own Fedora.  End of topic.
>
> -- 
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
>
> Was I helpful?  Let others know:
>  http://svcs.affero.net/rm.php?r=jkeating
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From byte at aeon.com.my  Wed Jul  6 06:07:13 2005
From: byte at aeon.com.my (Colin Charles)
Date: Wed, 06 Jul 2005 14:07:13 +0800
Subject: Has anyone got rhel3 running under fc4 as a domu
In-Reply-To: <9d5ddd1f05063007381ffee524@mail.gmail.com>
References: <9d5ddd1f05063007381ffee524@mail.gmail.com>
Message-ID: <1120630033.18983.127.camel@potter.soho.bytebot.net>

On Thu, 2005-06-30 at 15:38 +0100, Dan Track wrote:
> Hi,
> 
> I'm looking for someone who can help me get rhel3 running under fc4 as a domU.

Probably no. RHEL3 contains a 2.4 kernel, and it doesn't even have a Xen
kernel there. To install inside FC4, the said OS should have a
kernel-xen* iirc

So, installing Rawhide inside FC-4, should work provided the Xen builds
were present (I have a FC-4, within FC-4 upgraded to Rawhide root
working just fin)

-- 
Colin Charles, http://www.bytebot.net/



From rc040203 at freenet.de  Wed Jul  6 07:24:34 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 06 Jul 2005 09:24:34 +0200
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120618970.15363.73.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120618970.15363.73.camel@ignacio.ignacio.lan>
Message-ID: <1120634675.30532.101.camel@mccallum.corsepiu.local>

On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote:
> Okay, *almost* there.
> 
> Which of these files are important?

These are a side effect of a bug somewhere [1]:
>    /usr/bin/stVv16b0
>    /usr/bin/stdTtJd1
>    /usr/bin/stnIJwI1
>    /usr/bin/stxfFoJZ

These are not of any importance on linux targets:
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/gsyslimits.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/README
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/float.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/iso646.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/limits.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdarg.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdbool.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stddef.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/unwind.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/varargs.h
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/macro_list
>    /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/mkheaders.conf
>    /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fix-header
>    /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixinc.sh
>    /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixproto

More side-effects of the before mentioned bug
>    /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/stXW4r1X
>    /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stb6V9S0
>    /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stzwRUzZ

Don't know about this one:
>    /usr/libexec/getconf/default


> http://fedora.ivazquez.net/files/current/
BTW:

1. This line from your spec is meaningless for mipsel targets (and bogus
for i386 targets):
cp -a libstdc++-v3/config/cpu/i{4,3}86/atomicity.h

2. You'll also probably want to add
--enable-version-specific-runtime-libs
to the args being passed to configure.

Ralf

[1] I don't know about the cause, but I am occasionally seeing them with
my toolchains too.




From buildsys at redhat.com  Wed Jul  6 11:13:53 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 6 Jul 2005 07:13:53 -0400
Subject: rawhide report: 20050706 changes
Message-ID: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>

New package jorm
	Java(tm) Object Repository Mapping

New package jorm-rdb-adapter
	Database adaptor package for JORM

New package medor
	Middleware Enabling Distributed Object Requests

New package medor-expression
	Middleware Enabling Distributed Object Requests

New package perseus-concurrency
	Perseus concurrency manager component

New package perseus-fos
	Perseus FOS component

New package perseus-persistence
	Perseus persistence component

New package perseus-pool
	Perseus pool component


 
Updated Packages:

OpenIPMI-1.4.14-3
-----------------
* Mon Jul 04 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.12-3
- Updated versions of the initscripts and sysconf files
- Fixed typo in preun script and changelog

eclipse-pydev-1:0.9.3_fc-8
--------------------------
* Tue Jul 05 2005 Jeff Pound <jpound at redhat.com> 0.9.3_fc-8
- Apply Robin Greens patch to explicitly specify archive format (bz#162517)
- Fix spec file description.

epiphany-1.7.1-3
----------------
* Tue Jul 05 2005 Christopher Aillon <caillon at redhat.com> - 1.7.1-3
- Add the packages needed for building against -devel to its Requires:
- Add builds for ia64 s390(x)

* Thu Jun 16 2005 Christopher Aillon <caillon at redhat.com> - 1.7.1-2
- Specfile cleanup
- Make the devel package depend on the main package

gnome-icon-theme-2.10.1-5
-------------------------
* Tue Jul 05 2005 John (J5) Palmieri <johnp at redhat.com> - 2.10.1-5
- replace some upstream icons with redone ones

gnutls-1.0.25-2
---------------
* Mon Jul 04 2005 Tomas Mraz <tmraz at redhat.com> 1.0.25-2
- split the command line tools to utils subpackage

gtk-doc-1.4-1
-------------
* Wed Jul 06 2005 Matthias Clasen <mclasen at redhat.com> 1.4-1
- update to 1.4

gtk2-2.7.1-1
------------
* Fri Jul 01 2005 Matthias Clasen <mclasen at redhat.com>
- Update to 2.7.1

* Tue Jun 21 2005 Matthias Clasen <mclasen at redhat.com>
- update to 2.7.0
- bump requirements

* Tue May 10 2005 Matthias Clasen <mclasen at redhat.com>
- remove the openssl prereq again, as it did not fix
  Florians problem.

jonas-0:4.3.3-1jpp_5fc
----------------------
* Tue Jul 05 2005 Gary Benson <gbenson at redhat.com> - 4.3.3-1jpp_5fc
- Don't use PostgreSQL as the default datasource.

* Tue Jul 05 2005 Gary Benson <gbenson at redhat.com> - 4.3.3-1jpp_4fc
- Build with system jorm, medor and perseus.
- Work with PostgreSQL 8 (from Bryce McKinlay).

kdegraphics-7:3.4.1-2
---------------------
* Mon Jul 04 2005 Than Ngo <than at redhat.com> 7:3.4.1-2
- apply gcc4 workaround to fix #162430

kdepim-6:3.4.1-2
----------------
* Mon Jul 04 2005 Than Ngo <than at redhat.com> 6:3.4.1-2
- fix uninitialized variable warning #162311, #162312

kernel-2.6.12-1.1421_FC5
------------------------
* Tue Jul 05 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc1-git7
- Radeon power saving for another T41 (#159791)
- Drop x86-64 SMP kernels, and make generic kernel use SMP.
- Add pci table to advansys scsi driver. (#162431)

php-5.0.4-10.3
--------------
* Mon Jul 04 2005 Joe Orton <jorton at redhat.com> 5.0.4-10.3
- pear: update to XML_RPC 1.3.1 (CAN-2005-1921, #162045)
- update bundled shtool to 2.0.2 (CAN-2005-1751, #158998)

* Tue Jun 21 2005 Joe Orton <jorton at redhat.com> 5.0.4-10.2
- fix imports from dom module (Rob Richards, #161447)
- fix detection and support for ldap_start_tls (#160527)
- fix imagettftext et al (upstream, #161001)
- mark php.ini and php.conf as noreplace again for updates

pm-utils-0.03-1
---------------

selinux-policy-strict-1.24-4
----------------------------
* Tue Jul 05 2005 Dan Walsh <dwalsh at redhat.com> 1.24-4
- Allow dovecot to access cert_t
- Add redhat tunable

selinux-policy-targeted-1.24-4
------------------------------
* Tue Jul 05 2005 Dan Walsh <dwalsh at redhat.com> 1.24-4
- Allow dovecot to access cert_t
- Add redhat tunable

wget-1.10-3
-----------
* Tue Jul 05 2005 Karsten Hopp <karsten at redhat.de> 1.10-3
- fix minor documentation bug
- fix --no-cookies crash

* Mon Jul 04 2005 Karsten Hopp <karsten at redhat.de> 1.10-2
- update to wget-1.10
  - drop passive-ftp patch, already in 1.10
  - drop CVS patch
  - drop LFS patch, similar fix in 1.10
  - drop protdir patch, similar fix in 1.10
  - drop actime patch, already in 1.10

xorg-x11-6.8.2-41
-----------------
* Mon Jul 04 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-41
- Added xorg-x11-6.8.2-nv-driver-CVSHEAD-6.8.99.13.patch backport of CVS head
  nv driver to track the latest bug fixes and hardware support.  Hopefully
  this will also fix critical bug (#157715) also.
- Disabled patches that are included in the above nv driver update patch:
  - xorg-x11-6.8.3-nv-hw-fdo2533-1896.patch
  - xorg-x11-6.8.3-nv-patch-fdo2380-1752.patch

Broken deps for x86_64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for i386
----------------------------------------------------------
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	selinux-policy-targeted-sources - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-strict - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	selinux-policy-targeted - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	selinux-policy-strict-sources - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5



Broken deps for s390
----------------------------------------------------------
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	selinux-policy-targeted - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	selinux-policy-strict - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	selinux-policy-strict-sources - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	selinux-policy-targeted-sources - 1.24-4.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis



Broken deps for ppc64
----------------------------------------------------------
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	firstboot - 1.3.42-1.noarch requires system-config-display
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	rhpl - 0.168-1.ppc64 requires pyxf86config >= 0:0.3.2
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	rgmanager - 1.9.31-3.ia64 requires ccs
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper





From ivazquez at ivazquez.net  Wed Jul  6 11:24:15 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Wed, 06 Jul 2005 07:24:15 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120634675.30532.101.camel@mccallum.corsepiu.local>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120618970.15363.73.camel@ignacio.ignacio.lan>
	<1120634675.30532.101.camel@mccallum.corsepiu.local>
Message-ID: <1120649055.15363.75.camel@ignacio.ignacio.lan>

On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
> On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote:
> These are a side effect of a bug somewhere [1]:
> >    /usr/bin/stVv16b0
> >    /usr/bin/stdTtJd1
> >    /usr/bin/stnIJwI1
> >    /usr/bin/stxfFoJZ

It looks like a bug in strip whereby it doesn't remove the temporary
file if it doesn't recognize the file format.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/286b666c/attachment.sig>

From rc040203 at freenet.de  Wed Jul  6 12:12:57 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 06 Jul 2005 14:12:57 +0200
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120649055.15363.75.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120618970.15363.73.camel@ignacio.ignacio.lan>
	<1120634675.30532.101.camel@mccallum.corsepiu.local>
	<1120649055.15363.75.camel@ignacio.ignacio.lan>
Message-ID: <1120651978.30532.110.camel@mccallum.corsepiu.local>

On Wed, 2005-07-06 at 07:24 -0400, Ignacio Vazquez-Abrams wrote:
> On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
> > On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote:
> > These are a side effect of a bug somewhere [1]:
> > >    /usr/bin/stVv16b0
> > >    /usr/bin/stdTtJd1
> > >    /usr/bin/stnIJwI1
> > >    /usr/bin/stxfFoJZ
> 
> It looks like a bug in strip whereby it doesn't remove the temporary
> file if it doesn't recognize the file format.
Sounds plausible to me. If this holds, the origin of these files
probably is brp-strip-*, because it blindly runs strip rsp.
"<target>-strip" on all binaries and doesn't distinguish between foreign
and native binaries.

A straight forward work-around would be to hard-code the directories
containing native/foreign binaries into brp-*.

Ralf




From arjanv at redhat.com  Wed Jul  6 12:13:15 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 06 Jul 2005 14:13:15 +0200
Subject: rawhide report: 20050706 changes
In-Reply-To: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
Message-ID: <1120651996.4537.13.camel@laptopd505.fenrus.org>

On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
> - Drop x86-64 SMP kernels, and make generic kernel use SMP.

why is this??

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/6f829f99/attachment.sig>

From twoerner at redhat.com  Wed Jul  6 12:34:40 2005
From: twoerner at redhat.com (Thomas Woerner)
Date: Wed, 06 Jul 2005 14:34:40 +0200
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120651996.4537.13.camel@laptopd505.fenrus.org>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
Message-ID: <42CBCFE0.80107@redhat.com>

Arjan van de Ven wrote:
> On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
> 
>>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
> 
> 
> why is this??
> 
> 

Why only for x86_64?




From ph18 at cornell.edu  Wed Jul  6 12:41:28 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 06 Jul 2005 08:41:28 -0400
Subject: physical distances vs. net distances
In-Reply-To: <1120536751.3895.8.camel@yoda.loki.me>
References: <42CB31E6.605@sbcglobal.net> <1120620614.5801.7.camel@localhost>
	<1120536751.3895.8.camel@yoda.loki.me>
Message-ID: <42CBD178.5020709@cornell.edu>

Jesse Keating wrote:

>
>>
>>For the most part, intra-continental routing has little difference to
>>your download speed, unless it is something like Alaska to Florida or
>>Seattle to New York type thing.  Usually very very high bandwidth lines
>>are used in such long jumps before breaking down into lower bandwidth
>>and dispersing out over an area.  However INTER-continental traffic has
>>to go under the pond if you will and there is a lot of latency (and
>>cost) there.  This is why using a mirror in your country or continent
>>will be much more preferred than crossing an ocean to get your files.
>>    
>>
    I've been watching intercontiental internet performance since '89,  
and I can say that performance (for long transfers) depends more on the 
load factor of the connection than anything else.  Around that time,  
Finland had a particularly good connection to the US,  and funet had 
faster downloads than most sites in the US.

    Generally,  usage of an international link varies diurnally and 
weekly -- it was horrible (often 30% packet loss) connecting to the 
states from Germany in 1999 during the day,  but on a German holiday,  
the transatlantic line was so fast that the US backbone felt faster than 
it had felt a year ago to me.

    Around 2001 I was working with a startup in Brazil,  and we noticed 
a different pattern:  the link to the US was blisteringly fast during 
the work day,  but slowed to a crawl around midnight -- it turned out 
that Brazillians logged on en masse after 11 pm,  when phone rates dropped.

    The deployment of Random Early Drop around 2000 or so made a big 
difference in international line performance.  Back in 1999,  I'd make 
graphs of the Germany-US link connection saturating in the morning,  
ping times increasing from about 400 ms to 1200 ms,  horrible packet 
loss kicking in only when the buffers were filled up.  The Brazil-US 
connection circa 2001,  on the other hand,  would start dropping packets 
at a low rate long before saturation,  which kept the connection running 
smoothly if slowly.

    In some countries,  like India and South Africa,  I get the 
impression that the international connection isn't the bottleneck to 
most sites,  but that the domestic network (at least between us and the 
places that we've got equipment) is overloaded.



From ivazquez at ivazquez.net  Wed Jul  6 12:49:59 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Wed, 06 Jul 2005 08:49:59 -0400
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120651978.30532.110.camel@mccallum.corsepiu.local>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120618970.15363.73.camel@ignacio.ignacio.lan>
	<1120634675.30532.101.camel@mccallum.corsepiu.local>
	<1120649055.15363.75.camel@ignacio.ignacio.lan>
	<1120651978.30532.110.camel@mccallum.corsepiu.local>
Message-ID: <1120654199.15363.84.camel@ignacio.ignacio.lan>

On Wed, 2005-07-06 at 14:12 +0200, Ralf Corsepius wrote:
> On Wed, 2005-07-06 at 07:24 -0400, Ignacio Vazquez-Abrams wrote:
> > On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
> > > On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote:
> > > These are a side effect of a bug somewhere [1]:
> > > >    /usr/bin/stVv16b0
> > > >    /usr/bin/stdTtJd1
> > > >    /usr/bin/stnIJwI1
> > > >    /usr/bin/stxfFoJZ
> > 
> > It looks like a bug in strip whereby it doesn't remove the temporary
> > file if it doesn't recognize the file format.
> Sounds plausible to me. If this holds, the origin of these files
> probably is brp-strip-*, because it blindly runs strip rsp.
> "<target>-strip" on all binaries and doesn't distinguish between foreign
> and native binaries.
> 
> A straight forward work-around would be to hard-code the directories
> containing native/foreign binaries into brp-*.

Or to patch binutils to not leave its junk lying around.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/3f071ef1/attachment.sig>

From rc040203 at freenet.de  Wed Jul  6 12:54:15 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 06 Jul 2005 14:54:15 +0200
Subject: gcc cross-compiler for mipsel
In-Reply-To: <1120654199.15363.84.camel@ignacio.ignacio.lan>
References: <1120541334.15363.41.camel@ignacio.ignacio.lan>
	<1120618970.15363.73.camel@ignacio.ignacio.lan>
	<1120634675.30532.101.camel@mccallum.corsepiu.local>
	<1120649055.15363.75.camel@ignacio.ignacio.lan>
	<1120651978.30532.110.camel@mccallum.corsepiu.local>
	<1120654199.15363.84.camel@ignacio.ignacio.lan>
Message-ID: <1120654455.30532.113.camel@mccallum.corsepiu.local>

On Wed, 2005-07-06 at 08:49 -0400, Ignacio Vazquez-Abrams wrote:
> On Wed, 2005-07-06 at 14:12 +0200, Ralf Corsepius wrote:
> > On Wed, 2005-07-06 at 07:24 -0400, Ignacio Vazquez-Abrams wrote:
> > > On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
> > > > On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote:
> > > > These are a side effect of a bug somewhere [1]:
> > > > >    /usr/bin/stVv16b0
> > > > >    /usr/bin/stdTtJd1
> > > > >    /usr/bin/stnIJwI1
> > > > >    /usr/bin/stxfFoJZ
> > > 
> > > It looks like a bug in strip whereby it doesn't remove the temporary
> > > file if it doesn't recognize the file format.
> > Sounds plausible to me. If this holds, the origin of these files
> > probably is brp-strip-*, because it blindly runs strip rsp.
> > "<target>-strip" on all binaries and doesn't distinguish between foreign
> > and native binaries.
> > 
> > A straight forward work-around would be to hard-code the directories
> > containing native/foreign binaries into brp-*.
> 
> Or to patch binutils to not leave its junk lying around.
s/Or/And/

These actually are 2 independent issues. brp-*'s deficiencies trigger a
bug in binutils.

Ralf




From prarit at sgi.com  Wed Jul  6 13:35:04 2005
From: prarit at sgi.com (Prarit Bhargava)
Date: Wed, 06 Jul 2005 09:35:04 -0400
Subject: [PATCH/RFC]: CONFIG_NR_CPUS to 512
Message-ID: <42CBDE08.1030700@sgi.com>

I'd like to see the supported number of CPUs jump from 64 to 512 so that it 
would be possible to run Fedora Core 5 on large CPU systems.

Covered by BZ #162570.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.diff
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/758cddc1/attachment.ksh>

From arjanv at redhat.com  Wed Jul  6 13:52:50 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 06 Jul 2005 15:52:50 +0200
Subject: [PATCH/RFC]: CONFIG_NR_CPUS to 512
In-Reply-To: <42CBDE08.1030700@sgi.com>
References: <42CBDE08.1030700@sgi.com>
Message-ID: <1120657971.4537.18.camel@laptopd505.fenrus.org>

On Wed, 2005-07-06 at 09:35 -0400, Prarit Bhargava wrote:
> I'd like to see the supported number of CPUs jump from 64 to 512 so that it 
> would be possible to run Fedora Core 5 on large CPU systems.


you don't say which architecture this is for... I assume x86-64 since
nobody in their right mind would put 512 cpus in an 32 bit x86 box ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/b862a866/attachment.sig>

From prarit at sgi.com  Wed Jul  6 14:11:42 2005
From: prarit at sgi.com (Prarit Bhargava)
Date: Wed, 06 Jul 2005 10:11:42 -0400
Subject: [PATCH/RFC]: CONFIG_NR_CPUS to 512
In-Reply-To: <1120657971.4537.18.camel@laptopd505.fenrus.org>
References: <42CBDE08.1030700@sgi.com>
	<1120657971.4537.18.camel@laptopd505.fenrus.org>
Message-ID: <42CBE69E.3040408@sgi.com>

Arjan van de Ven wrote:
> 
> you don't say which architecture this is for... I assume x86-64 since
> nobody in their right mind would put 512 cpus in an 32 bit x86 box ;)
> 
> 
> 

Oops.  My bad, Arjan.  ia64 :)

P.



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Wed Jul  6 14:36:58 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Wed, 6 Jul 2005 16:36:58 +0200
Subject: [PATCH/RFC]: CONFIG_NR_CPUS to 512
In-Reply-To: <42CBE69E.3040408@sgi.com>
References: <42CBDE08.1030700@sgi.com>
	<1120657971.4537.18.camel@laptopd505.fenrus.org>
	<42CBE69E.3040408@sgi.com>
Message-ID: <20050706163658.26428958@python2>

Prarit Bhargava wrote :

> Arjan van de Ven wrote:
> > 
> > you don't say which architecture this is for... I assume x86-64 since
> > nobody in their right mind would put 512 cpus in an 32 bit x86 box ;)
> 
> Oops.  My bad, Arjan.  ia64 :)

...and you want the max to become the total number of ia64 processors
Intel has manufactured? :-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3
Load : 0.48 0.60 0.53



From mricon at gmail.com  Wed Jul  6 15:00:07 2005
From: mricon at gmail.com (Konstantin Ryabitsev)
Date: Wed, 6 Jul 2005 11:00:07 -0400
Subject: eclipse-pydev and bundled pylint
In-Reply-To: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
Message-ID: <f8f6300f0507060800640ce63e@mail.gmail.com>

On 06/07/05, Build System <buildsys at redhat.com> wrote:
> eclipse-pydev-1:0.9.3_fc-8
> --------------------------
> * Tue Jul 05 2005 Jeff Pound <jpound at redhat.com> 0.9.3_fc-8
> - Apply Robin Greens patch to explicitly specify archive format (bz#162517)
> - Fix spec file description.

Does eclipse-pydev still come with bundled pylint in devel? Is that
really a good idea?

I have packaged pylint in Extras, so maybe it makes more sense to
incorporate it into the core, or not bundle pylint with pydev in the
first place and just let the users install pylint on their own?

Regards,
-- 
Konstantin Ryabitsev
Zlotniks, INC

"???????? ?????????? ????? ? ??????? ???? ?????."



From nicolas.mailhot at laposte.net  Wed Jul  6 15:27:14 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 6 Jul 2005 17:27:14 +0200 (CEST)
Subject: weird representation for FFFD
In-Reply-To: <42C01D5C.6030107@draigBrady.com>
References: <42C00042.3010307@draigBrady.com>
	<1119882800.5260.141.camel@localhost.localdomain>
	<42C01D5C.6030107@draigBrady.com>
Message-ID: <7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>


On Lun 27 juin 2005 17:38, P at draigBrady.com wrote:
> Simos Xenitellis wrote:
>> ???????? 27/????????/2005, ?????????? ?????
???????? ?????? ??????
>> 14:33, ??/?? P at draigBrady.com
>> ????????????:
>>
>>>On my fedora core 3 gnome desktop,
>>>I get a weird representation for U+FFFD.
>>>Here's what it looks like for you [???].
>>>
>>>It's the "REPLACEMENT CHARACTER", and according
>>>to the following should be question mark enclosed
>>>in a solid diamond: http://www.unicode.org/charts/PDF/UFFF0.pdf
>>>I've been told that this is also the representation
>>>on windows and OSX.
>>>
>>>However I'm getting a weird comma like thing, which
>>>Markus Kuhn _has_ made reference to here I think:
>>>http://www.w3.org/2001/06/utf-8-wrong/UTF-8-test.html
>>>In the gnome charmap applet it seems to be the nimbus
>>>and schoolbook (sans and serif) fallback fonts that have
>>>this weird representation. The (Misc) Fixed fonts
>>>do have the question mark as expected.
>>>
>>>So why this weird representation?
>>>I'm writing an app where I would like to display
>>>characters that are invalid in the current encoding,
>>>and the comma like thing it totally confusing for users.
>>
>>
>> Hi,
>> On my system (FC2), gucharmap says it's FreeSans.
>> Doesn't FC3 have FreeSans/FreeSerif/FreeMono?
>
> Right so bitstream-vera doesn't even have the FFFD char,
> and the fallback nimbus has this weird comma like thing.
>
> I don't think freefont is part of fedora.

dejavu just made it in fedora extras. Does it have the same problem ?
(if the answer is yes the dejavu people seem to fix their fonts pretty
fast - just make them release a fixed version and I'll respin the dejavu
package)

As for freefont I've never used it. If it's not a Vera derivative and is
half decent I may be coaxed into packaging it for FE. Otherwise I've
already decided dejavu is the only project that is trying hard to merge
all the Vera variants in an open way so I won't push any other
Vera-derivative in FE now.

Regards,

-- 
Nicolas Mailhot



From P at draigBrady.com  Wed Jul  6 16:10:48 2005
From: P at draigBrady.com (P at draigBrady.com)
Date: Wed, 06 Jul 2005 17:10:48 +0100
Subject: weird representation for FFFD
In-Reply-To: <7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>
References: <42C00042.3010307@draigBrady.com>	<1119882800.5260.141.camel@localhost.localdomain>	<42C01D5C.6030107@draigBrady.com>
	<7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>
Message-ID: <42CC0288.3050409@draigBrady.com>

Nicolas Mailhot wrote:
>>I don't think freefont is part of fedora.

No it's not.

> dejavu just made it in fedora extras. Does it have the same problem ?
> (if the answer is yes the dejavu people seem to fix their fonts pretty
> fast - just make them release a fixed version and I'll respin the dejavu
> package)

http://dejavu.sourceforge.net
Cool. It still doesn't have the "standard" U+FFFD char (?) though :(

> As for freefont I've never used it. If it's not a Vera derivative and is
> half decent I may be coaxed into packaging it for FE. Otherwise I've
> already decided dejavu is the only project that is trying hard to merge
> all the Vera variants in an open way so I won't push any other
> Vera-derivative in FE now.

http://www.nongnu.org/freefont/
It's not a vera derivative, and having used it for a week
or so, I've noticed kerning issues especially at smaller
font sizes. It might be a good fall back though, or as
a base for merging into dejavu? It really covers a huge
amount of unicode characters.

-- 
P?draig Brady - http://www.pixelbeat.org
--



From Nicolas.Mailhot at laPoste.net  Wed Jul  6 17:02:11 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 06 Jul 2005 19:02:11 +0200
Subject: weird representation for FFFD
In-Reply-To: <42CC0288.3050409@draigBrady.com>
References: <42C00042.3010307@draigBrady.com>
	<1119882800.5260.141.camel@localhost.localdomain>
	<42C01D5C.6030107@draigBrady.com>
	<7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>
	<42CC0288.3050409@draigBrady.com>
Message-ID: <1120669332.17357.7.camel@rousalka.dyndns.org>

Le mercredi 06 juillet 2005 ? 17:10 +0100, P at draigBrady.com a ?crit :
> Nicolas Mailhot wrote:
> >>I don't think freefont is part of fedora.
> 
> No it's not.
> 
> > dejavu just made it in fedora extras. Does it have the same problem ?
> > (if the answer is yes the dejavu people seem to fix their fonts pretty
> > fast - just make them release a fixed version and I'll respin the dejavu
> > package)
> 
> http://dejavu.sourceforge.net
> Cool. It still doesn't have the "standard" U+FFFD char (?) though :(
> 
> > As for freefont I've never used it. If it's not a Vera derivative and is
> > half decent I may be coaxed into packaging it for FE. Otherwise I've
> > already decided dejavu is the only project that is trying hard to merge
> > all the Vera variants in an open way so I won't push any other
> > Vera-derivative in FE now.
> 
> http://www.nongnu.org/freefont/
> It's not a vera derivative, and having used it for a week
> or so, I've noticed kerning issues especially at smaller
> font sizes. It might be a good fall back though, or as
> a base for merging into dejavu? It really covers a huge
> amount of unicode characters.

Well, Fedora already has its share of ugly fonts with wide unicode
coverage. As we're only talking about a single character here, that does
not seem too difficult to create (just add a black diamond to a question
mark), I'd suggest you just get it into dejavu and I'll get the new
dejavu version into Fedora Extras.

If you're quick it'll be available for users by early august.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/9d815c84/attachment.sig>

From davej at redhat.com  Wed Jul  6 17:09:30 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 13:09:30 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <dagimk$fi$1@sea.gmane.org>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<dagimk$fi$1@sea.gmane.org>
Message-ID: <20050706170930.GA1942@redhat.com>

On Wed, Jul 06, 2005 at 07:26:59AM -0500, Ian Pilcher wrote:
 > Arjan van de Ven wrote:
 > >On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
 > >
 > >>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
 > >why is this??
 > 
 > Presumably it's because so many processors these days are either Hyper-
 > Threaded or (soon) dual-core.  At some point, the benefit of building
 > and shipping uni-processor kernels is less than the cost.

Indeed.  The proportion of UP vs SMP x86-64's out there is only
going to increase in favour of SMP.  Last numbers I read showed
that HT EM64T's outsold AMD64's already.  As the UP kernel gets
less and less testing moving forward, it doesn't really offer
any great benefit to shipping it. Especially as the performance
overheads of running SMP locking on UP is negligable.

Finally, there's going to be an extra set of kernels for x86-64 xen
at some point, which pushes the total number of kernels up yet again.
As we're constantly battling for CD space, this tradeoff seemed worth it.

If test1 goes out, and it blows up horribly (ie, there are lots of
single CPU x86-64 boxes out there which can't run the SMP kernel)
we'll look at reconsidering this decision.  Given x86-64 doesn't have
the crappy lineage that it's 32bit predecessor has, I'm confident that
this won't be the case.

		Dave



From davej at redhat.com  Wed Jul  6 17:17:25 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 13:17:25 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <42CBCFE0.80107@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com>
Message-ID: <20050706171725.GB1942@redhat.com>

On Wed, Jul 06, 2005 at 02:34:40PM +0200, Thomas Woerner wrote:
 > Arjan van de Ven wrote:
 > >On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
 > >
 > >>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
 > >why is this??
 > Why only for x86_64?

32 bit has a lot more history of crap hardware.  It's almost
guaranteed that there are 32bit UP boxes out there that won't
boot the SMP kernel.
(In fact, it's certainly guaranteed because the 686-smp kernel
 uses PAE, which not all 686's have)

x86-64 has had an APIC since day 1.  It hasn't had to worry
about crap like PAE.  As it doesn't have this baggage, the
decision is a lot easier to make there.

I spent a while going over the list of current 32bit kernels
trying to figure out a way to drop one of them.

- Dropping 586 kernels would likely get AMD K5/K6, Cyrix, VIA users
  screaming.
- Forcing all the non-PAE CPUs to use the 586 kernel and dropping
  the 686-UP kernel would get all the "my kernel isn't optimised
  for my hardware" people screaming.

So 32-bit is very likely going to stay exactly the way it is today.

One change that might happen though -- there are newer CPUs that
have (or will have soon) NX capability, but aren't SMP.
(VIA have a chip ready, Intel are alleged to be putting NX in their
 next line of laptop processors, probably AMD too).

To take advantage of NX, you need PAE enabled, which means these
kernels will need to run 686-smp even though they aren't smp.
I'll probably be doing some lobbying in Jeremy's cube for an
installer change on this hardware when I get some to test with.

Given that using NX on 32bit is a big win due to us being able
to use sysenter again, this is a very attractive feature.

		Dave



From prarit at sgi.com  Wed Jul  6 17:51:47 2005
From: prarit at sgi.com (Prarit Bhargava)
Date: Wed, 06 Jul 2005 13:51:47 -0400
Subject: [PATCH/RFC]: CONFIG_NR_CPUS to 512
In-Reply-To: <20050706163658.26428958@python2>
References: <42CBDE08.1030700@sgi.com>	<1120657971.4537.18.camel@laptopd505.fenrus.org>	<42CBE69E.3040408@sgi.com>
	<20050706163658.26428958@python2>
Message-ID: <42CC1A33.2010807@sgi.com>

Matthias Saou wrote:

> 
> ...and you want the max to become the total number of ia64 processors
> Intel has manufactured? :-)

:)

Funny, very funny ... actually I'm hoping to run a kernel on one of these:

http://www.nas.nasa.gov/About/Projects/Columbia/columbia.html

P.

> 
> Matthias
> 



From Nicolas.Mailhot at laPoste.net  Wed Jul  6 17:53:06 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 06 Jul 2005 19:53:06 +0200
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706170930.GA1942@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<dagimk$fi$1@sea.gmane.org>  <20050706170930.GA1942@redhat.com>
Message-ID: <1120672386.17867.1.camel@rousalka.dyndns.org>

Le mercredi 06 juillet 2005 ? 13:09 -0400, Dave Jones a ?crit :
> On Wed, Jul 06, 2005 at 07:26:59AM -0500, Ian Pilcher wrote:
>  > Arjan van de Ven wrote:
>  > >On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
>  > >
>  > >>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
>  > >why is this??
>  > 
>  > Presumably it's because so many processors these days are either Hyper-
>  > Threaded or (soon) dual-core.  At some point, the benefit of building
>  > and shipping uni-processor kernels is less than the cost.
> 
> Indeed.  The proportion of UP vs SMP x86-64's out there is only
> going to increase in favour of SMP. 

And anyway can't we expect a full RT preempt kernel soonish ? As long as
we're making everyone SMP. 

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/92e3b199/attachment.sig>

From davej at redhat.com  Wed Jul  6 17:56:23 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 13:56:23 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120672386.17867.1.camel@rousalka.dyndns.org>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<dagimk$fi$1@sea.gmane.org> <20050706170930.GA1942@redhat.com>
	<1120672386.17867.1.camel@rousalka.dyndns.org>
Message-ID: <20050706175623.GA24129@redhat.com>

On Wed, Jul 06, 2005 at 07:53:06PM +0200, Nicolas Mailhot wrote:
 > Le mercredi 06 juillet 2005 ? 13:09 -0400, Dave Jones a ?crit :
 > > On Wed, Jul 06, 2005 at 07:26:59AM -0500, Ian Pilcher wrote:
 > >  > Arjan van de Ven wrote:
 > >  > >On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
 > >  > >
 > >  > >>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
 > >  > >why is this??
 > >  > 
 > >  > Presumably it's because so many processors these days are either Hyper-
 > >  > Threaded or (soon) dual-core.  At some point, the benefit of building
 > >  > and shipping uni-processor kernels is less than the cost.
 > > 
 > > Indeed.  The proportion of UP vs SMP x86-64's out there is only
 > > going to increase in favour of SMP. 
 > 
 > And anyway can't we expect a full RT preempt kernel soonish ? As long as
 > we're making everyone SMP. 

Current fc5 kernels are preemptable using voluntary preemption,
and have been for about a week or so.

		Dave




From jkeating at j2solutions.net  Wed Jul  6 18:16:51 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 06 Jul 2005 11:16:51 -0700
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706171725.GB1942@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com>  <20050706171725.GB1942@redhat.com>
Message-ID: <1120673811.12159.92.camel@prometheus.gamehouse.com>

On Wed, 2005-07-06 at 13:17 -0400, Dave Jones wrote:
> To take advantage of NX, you need PAE enabled, which means these
> kernels will need to run 686-smp even though they aren't smp.
> I'll probably be doing some lobbying in Jeremy's cube for an
> installer change on this hardware when I get some to test with.
> 
> Given that using NX on 32bit is a big win due to us being able
> to use sysenter again, this is a very attractive feature.
> 

What is the situation for x86_64 processors running in 32bit mode?  Is
it advantageous for Athlon64 32bit people to install the i686-smp kernel
today?  (yes there are good reason for me to be using 32bit on my
Athlon64)

-- 
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



From Nicolas.Mailhot at laPoste.net  Wed Jul  6 18:12:17 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 06 Jul 2005 20:12:17 +0200
Subject: weird representation for FFFD
In-Reply-To: <m3oe9fzv11.fsf@lugabout.cloos.reno.nv.us>
References: <42C00042.3010307@draigBrady.com>
	<1119882800.5260.141.camel@localhost.localdomain>
	<42C01D5C.6030107@draigBrady.com>
	<7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>
	<m3oe9fzv11.fsf@lugabout.cloos.reno.nv.us>
Message-ID: <1120673538.18405.7.camel@rousalka.dyndns.org>

Le mercredi 06 juillet 2005 ? 13:47 -0400, James Cloos a ?crit :
> >>>>> "Nicolas" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:
> 
> Nicolas> dejavu just made it in fedora extras. Does it have the same
> Nicolas> problem ?  (if the answer is yes the dejavu people seem to
> Nicolas> fix their fonts pretty fast - just make them release a fixed
> Nicolas> version and I'll respin the dejavu package)

Thank you very much.
I must say it's a pleasure to see the DejaVu project thriving like any
other core FOSS project after all the various failures and dead ends on
the Linux font front.

Just continue like this and you'll create the corefonts of the FOSS
world.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/8b054aff/attachment.sig>

From janina at rednote.net  Wed Jul  6 18:14:22 2005
From: janina at rednote.net (Janina Sajka)
Date: Wed, 6 Jul 2005 13:14:22 -0500
Subject: physical distances vs. net distances
In-Reply-To: <42CB31E6.605@sbcglobal.net>
References: <42CB31E6.605@sbcglobal.net>
Message-ID: <20050706181422.GA11891@rednote.net>

I have noticed really good performance from a server in Ireland, where
other servers geographically close to me here in Maryland are doing far
more poorly. Go figure.

david writes:
> Jeff's comment about grabbing from a local mirror got me thinking about 
> distances to mirrors. So, I tried tracing the route to my local 
> University of Wisconsin, Madison mirror about 5 Miles down the road in 
> the Comp. Sci. building.  For some odd reason sbcglobal is routing that 
> traffic through Chicago, Ill and back, about a 300 mile round trip.  
> Pinging is fast and my dsl line to always maxed out.  There must be some 
> bizarrely fat pipes between Madison and Chicago;  I might as well look 
> for a mirror in Chicago.
> -dtf
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org

Janina Sajka				Phone: +1.202.494.7040
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more.



From bgerst at didntduck.org  Wed Jul  6 18:18:40 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Wed, 06 Jul 2005 14:18:40 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706171725.GB1942@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>	<1120651996.4537.13.camel@laptopd505.fenrus.org>	<42CBCFE0.80107@redhat.com>
	<20050706171725.GB1942@redhat.com>
Message-ID: <42CC2080.6090607@didntduck.org>

Dave Jones wrote:
> On Wed, Jul 06, 2005 at 02:34:40PM +0200, Thomas Woerner wrote:
>  > Arjan van de Ven wrote:
>  > >On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
>  > >
>  > >>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
>  > >why is this??
>  > Why only for x86_64?
> 
> 32 bit has a lot more history of crap hardware.  It's almost
> guaranteed that there are 32bit UP boxes out there that won't
> boot the SMP kernel.
> (In fact, it's certainly guaranteed because the 686-smp kernel
>  uses PAE, which not all 686's have)
> 
> x86-64 has had an APIC since day 1.  It hasn't had to worry
> about crap like PAE.  As it doesn't have this baggage, the
> decision is a lot easier to make there.

What about the bloat and slowdown because of the unnecessary spinlocks 
and more complex scheduler code?

--
				Brian Gerst



From davej at redhat.com  Wed Jul  6 18:24:18 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 14:24:18 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120673811.12159.92.camel@prometheus.gamehouse.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
Message-ID: <20050706182417.GA19696@redhat.com>

On Wed, Jul 06, 2005 at 11:16:51AM -0700, Jesse Keating wrote:
 > On Wed, 2005-07-06 at 13:17 -0400, Dave Jones wrote:
 > > To take advantage of NX, you need PAE enabled, which means these
 > > kernels will need to run 686-smp even though they aren't smp.
 > > I'll probably be doing some lobbying in Jeremy's cube for an
 > > installer change on this hardware when I get some to test with.
 > > 
 > > Given that using NX on 32bit is a big win due to us being able
 > > to use sysenter again, this is a very attractive feature.
 > > 
 > 
 > What is the situation for x86_64 processors running in 32bit mode?  Is
 > it advantageous for Athlon64 32bit people to install the i686-smp kernel
 > today?  (yes there are good reason for me to be using 32bit on my
 > Athlon64)

should work just fine, though I've not done a 32bit install on x86-64
for a long time (probably FC2 era).

		Dave



From jkeating at j2solutions.net  Wed Jul  6 18:51:03 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 06 Jul 2005 11:51:03 -0700
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706182417.GA19696@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
Message-ID: <1120675864.12159.94.camel@prometheus.gamehouse.com>

On Wed, 2005-07-06 at 14:24 -0400, Dave Jones wrote:
> should work just fine, though I've not done a 32bit install on x86-64
> for a long time (probably FC2 era).

Should work fine, or there is actual benefit to doing so?

-- 
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



From arjanv at redhat.com  Wed Jul  6 18:47:33 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 6 Jul 2005 20:47:33 +0200
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706171725.GB1942@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
Message-ID: <20050706184733.GA31770@devserv.devel.redhat.com>

On Wed, Jul 06, 2005 at 01:17:25PM -0400, Dave Jones wrote:
> One change that might happen though -- there are newer CPUs that
> have (or will have soon) NX capability, but aren't SMP.
> (VIA have a chip ready, Intel are alleged to be putting NX in their
>  next line of laptop processors, probably AMD too).

Intel's next laptop processor will be 64 bit tho.



From davej at redhat.com  Wed Jul  6 18:56:53 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 14:56:53 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120675864.12159.94.camel@prometheus.gamehouse.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
Message-ID: <20050706185653.GA25242@redhat.com>

On Wed, Jul 06, 2005 at 11:51:03AM -0700, Jesse Keating wrote:
 > On Wed, 2005-07-06 at 14:24 -0400, Dave Jones wrote:
 > > should work just fine, though I've not done a 32bit install on x86-64
 > > for a long time (probably FC2 era).
 > 
 > Should work fine, or there is actual benefit to doing so?

I'm confused. I think I missed the point of your original question.
The only real benefit of running the 32 bit kernel is if you have
some 32 bit application that doesn't work under 32bit-emulation of
the 64bit kernel.  There really shouldn't be that many of these.

		Dave



From alan at redhat.com  Wed Jul  6 18:59:37 2005
From: alan at redhat.com (Alan Cox)
Date: Wed, 6 Jul 2005 14:59:37 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <42CC2080.6090607@didntduck.org>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<42CC2080.6090607@didntduck.org>
Message-ID: <20050706185937.GA7892@devserv.devel.redhat.com>

On Wed, Jul 06, 2005 at 02:18:40PM -0400, Brian Gerst wrote:
> What about the bloat and slowdown because of the unnecessary spinlocks 
> and more complex scheduler code?

The locks shouldn't matter. AMD got locked operations on exclusive cache
lines right. Its generally only Intel boxes that had high lock costs. Not 
sure on the scheduler.

Alan



From koneko.em at gmail.com  Wed Jul  6 19:01:35 2005
From: koneko.em at gmail.com (Emily Brantley)
Date: Wed, 06 Jul 2005 15:01:35 -0400
Subject: Window Placement
Message-ID: <42CC2A8F.4000109@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Havoc Pennington's entry on his blog (aggregated at p.g.o and other
places) entitled "finished software" led me to think about metacity
again for the first time in a while.

Metacity is admirably stable as a tool; it's one part of my desktop that
never calls attention to itself with problems, glaring features, or
distractions.  I never think about it, rarely have to refer to it, and
hear few questions about it.

Yeah, if there were some piece of software in the desktop that I could
regard as in "maintenance mode", metacity would be it.  But the topic
got me to thinking about where room for improvement lay, but rather than
filing a bug, I wanted to ask for the general opinion on one thing:

Does the "best-fit" window placement algorithm annoy anyone else ?

After I open a couple of windows and all the vacant real-estate is gone,
all the rest proceed to overlap one another almost as perfectly as
possible all the way up in the top-left corner.  Placing windows
perfectly atop one another seems broken.

What's the logic ?  Is this an area for improvement/development ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCzCqNglUG+5Qgd5MRApkyAJ0ZSdGMNd5H3AsWyCOhRRqNlYiwcgCfQnF9
i2ZVIXt1+1r3ajxsa6b/xCo=
=Own9
-----END PGP SIGNATURE-----



From ivazquez at ivazquez.net  Wed Jul  6 19:18:01 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Wed, 06 Jul 2005 15:18:01 -0400
Subject: Window Placement
In-Reply-To: <42CC2A8F.4000109@gmail.com>
References: <42CC2A8F.4000109@gmail.com>
Message-ID: <1120677481.15363.102.camel@ignacio.ignacio.lan>

On Wed, 2005-07-06 at 15:01 -0400, Emily Brantley wrote:
> Does the "best-fit" window placement algorithm annoy anyone else ?
> 
> After I open a couple of windows and all the vacant real-estate is gone,
> all the rest proceed to overlap one another almost as perfectly as
> possible all the way up in the top-left corner.  Placing windows
> perfectly atop one another seems broken.

What you're describing is Metacity's behavior in FC3. It's even worse in
FC4. Every time I open a new window in FC4 I feel like throwing stuff
around because it doesn't seem to make any sense. When a couple of small
windows and opening a large one, Metacity will decide to mash the window
into some open space, best-fit or not. Combine that with the change that
opens new windows *under* the active window, and you have an excellent
recipe for GUI rage.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/2585959c/attachment.sig>

From davej at redhat.com  Wed Jul  6 19:32:45 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 15:32:45 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706185937.GA7892@devserv.devel.redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<42CC2080.6090607@didntduck.org>
	<20050706185937.GA7892@devserv.devel.redhat.com>
Message-ID: <20050706193245.GB25242@redhat.com>

On Wed, Jul 06, 2005 at 02:59:37PM -0400, Alan Cox wrote:
 > On Wed, Jul 06, 2005 at 02:18:40PM -0400, Brian Gerst wrote:
 > > What about the bloat and slowdown because of the unnecessary spinlocks 
 > > and more complex scheduler code?
 > 
 > The locks shouldn't matter. AMD got locked operations on exclusive cache
 > lines right. Its generally only Intel boxes that had high lock costs.

And the only UP EM64T's I've seen have HT. Though, that could be
disabled, but I expect that the folks disabling it are in a minority.

 > Not sure on the scheduler.

It'll degenerate to a single runqueue on UP, so there shouldn't
be any of the complicated balancing going on.  Bloat-wise, it's
a tiny amount of change.

		Dave



From jkeating at j2solutions.net  Wed Jul  6 19:42:26 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 06 Jul 2005 12:42:26 -0700
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706185653.GA25242@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
	<20050706185653.GA25242@redhat.com>
Message-ID: <1120678946.12159.98.camel@prometheus.gamehouse.com>

On Wed, 2005-07-06 at 14:56 -0400, Dave Jones wrote:
> 
> I'm confused. I think I missed the point of your original question.
> The only real benefit of running the 32 bit kernel is if you have
> some 32 bit application that doesn't work under 32bit-emulation of
> the 64bit kernel.  There really shouldn't be that many of these.

Heh, no.  What I meant was, on a 32bit platform, is there benefit to
running a smp kernel on a UP system?  Because it technically is an
x86_64 processor, it is just not running in x86_64 mode.

-- 
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



From mikem.rtp at gmail.com  Wed Jul  6 19:35:19 2005
From: mikem.rtp at gmail.com (Mike McLean)
Date: Wed, 6 Jul 2005 15:35:19 -0400
Subject: Build system - how to ?
In-Reply-To: <3c8c9c78b23d8fe2b09b930976469cac@tachegroup.com>
References: <4e02411ee5fe59441d2230b2fb6bad23@tachegroup.com>
	<1120570384.15277.4.camel@dcbw.boston.redhat.com>
	<3c8c9c78b23d8fe2b09b930976469cac@tachegroup.com>
Message-ID: <4f50e06805070612356d11d2aa@mail.gmail.com>

On 7/6/05, TGS <spam at tachegroup.com> wrote:
> As far as Fedora Core is concerned, does that mean that no body can
> see, understand, or even reproduce the Fedora Core build process,
> beehive? That does not seem too Open Source to me.

The source is provided in the form of source rpms.  The source rpms
include all the source, patches, and scripts that you need to rebuild
the packages.  You can build these rpms using the rpmbuild utility,
just like beehive does.  I fail to see how this is not enough.



From davej at redhat.com  Wed Jul  6 19:36:52 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 15:36:52 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120678946.12159.98.camel@prometheus.gamehouse.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
	<20050706185653.GA25242@redhat.com>
	<1120678946.12159.98.camel@prometheus.gamehouse.com>
Message-ID: <20050706193651.GA27630@redhat.com>

On Wed, Jul 06, 2005 at 12:42:26PM -0700, Jesse Keating wrote:
 > On Wed, 2005-07-06 at 14:56 -0400, Dave Jones wrote:
 > > 
 > > I'm confused. I think I missed the point of your original question.
 > > The only real benefit of running the 32 bit kernel is if you have
 > > some 32 bit application that doesn't work under 32bit-emulation of
 > > the 64bit kernel.  There really shouldn't be that many of these.
 > 
 > Heh, no.  What I meant was, on a 32bit platform, is there benefit to
 > running a smp kernel on a UP system?  Because it technically is an
 > x86_64 processor, it is just not running in x86_64 mode.

If your CPU supports NX, then the SMP kernel will use it, whereas
the UP kernel will use segment limits, and disable sysenter support.
If it doesn't support NX, there's no particular benefit.

		Dave



From koneko.em at gmail.com  Wed Jul  6 19:37:44 2005
From: koneko.em at gmail.com (Emily Brantley)
Date: Wed, 06 Jul 2005 15:37:44 -0400
Subject: Window Placement
In-Reply-To: <1120677481.15363.102.camel@ignacio.ignacio.lan>
References: <42CC2A8F.4000109@gmail.com>
	<1120677481.15363.102.camel@ignacio.ignacio.lan>
Message-ID: <42CC3308.9050805@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ignacio Vazquez-Abrams wrote:
> On Wed, 2005-07-06 at 15:01 -0400, Emily Brantley wrote:
> 
>>Does the "best-fit" window placement algorithm annoy anyone else ?
>>
>>After I open a couple of windows and all the vacant real-estate is gone,
>>all the rest proceed to overlap one another almost as perfectly as
>>possible all the way up in the top-left corner.  Placing windows
>>perfectly atop one another seems broken.
> 
> 
> What you're describing is Metacity's behavior in FC3. It's even worse in
> FC4. Every time I open a new window in FC4 I feel like throwing stuff
> around because it doesn't seem to make any sense. When a couple of small
> windows and opening a large one, Metacity will decide to mash the window
> into some open space, best-fit or not. Combine that with the change that
> opens new windows *under* the active window, and you have an excellent
> recipe for GUI rage.

Oh, you're very right.  Try dragging and dropping a link to the desktop
(which prompts you to link or download there).  That prompt dialog NEVER
has focus, requiring me to make the extra step of focusing it.  What
should be easier (dragging and dropping onto my desktop) becomes harder
than Saving As.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCzDMGglUG+5Qgd5MRAjCPAJ9RWaH1ymt/fmI6r48e2H9UIVAaFQCfblhf
Anc44r35nNAam4jsJpiVhDY=
=tu2X
-----END PGP SIGNATURE-----



From jpound at redhat.com  Wed Jul  6 19:40:41 2005
From: jpound at redhat.com (Jeff Pound)
Date: Wed, 06 Jul 2005 15:40:41 -0400
Subject: eclipse-pydev and bundled pylint
In-Reply-To: <f8f6300f0507060800640ce63e@mail.gmail.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<f8f6300f0507060800640ce63e@mail.gmail.com>
Message-ID: <1120678842.2662.40.camel@tower.toronto.redhat.com>

On Wed, 2005-07-06 at 11:00 -0400, Konstantin Ryabitsev wrote:
> On 06/07/05, Build System <buildsys at redhat.com> wrote:
> > eclipse-pydev-1:0.9.3_fc-8
> > --------------------------
> > * Tue Jul 05 2005 Jeff Pound <jpound at redhat.com> 0.9.3_fc-8
> > - Apply Robin Greens patch to explicitly specify archive format (bz#162517)
> > - Fix spec file description.
> 
> Does eclipse-pydev still come with bundled pylint in devel? Is that
> really a good idea?

The upstream Pydev project (http://pydev.sf.net) includes a few
third-party packages including pylint. Using the system installed pylint
would be ideal but it would require maintaining a forked version of
pydev in sync with the upstream releases. If you think it's worthwhile
to pursue, you should file a bug against the upstream pydev to have them
use separate packages for third party apps, and have pydev configurable
for these apps.


-- 
Jeff Pound <jpound at redhat.com>



From overholt at redhat.com  Wed Jul  6 19:43:24 2005
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 06 Jul 2005 15:43:24 -0400
Subject: eclipse-pydev and bundled pylint
In-Reply-To: <1120678842.2662.40.camel@tower.toronto.redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<f8f6300f0507060800640ce63e@mail.gmail.com>
	<1120678842.2662.40.camel@tower.toronto.redhat.com>
Message-ID: <1120679004.714.10.camel@tofu.toronto.redhat.com>

On Wed, 2005-06-07 at 15:40 -0400, Jeff Pound wrote:
> On Wed, 2005-07-06 at 11:00 -0400, Konstantin Ryabitsev wrote:
> > On 06/07/05, Build System <buildsys at redhat.com> wrote:
> > > eclipse-pydev-1:0.9.3_fc-8
> > > --------------------------
> > > * Tue Jul 05 2005 Jeff Pound <jpound at redhat.com> 0.9.3_fc-8
> > > - Apply Robin Greens patch to explicitly specify archive format (bz#162517)
> > > - Fix spec file description.
> > 
> > Does eclipse-pydev still come with bundled pylint in devel? Is that
> > really a good idea?
> 
> The upstream Pydev project (http://pydev.sf.net) includes a few
> third-party packages including pylint. Using the system installed pylint
> would be ideal but it would require maintaining a forked version of
> pydev in sync with the upstream releases. If you think it's worthwhile
> to pursue, you should file a bug against the upstream pydev to have them
> use separate packages for third party apps, and have pydev configurable
> for these apps.

We may want to carry a patch in the RPM to link to the system pylint (if
it was in FC).

Andrew



From jkeating at j2solutions.net  Wed Jul  6 20:02:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 06 Jul 2005 13:02:09 -0700
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706193651.GA27630@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
	<20050706185653.GA25242@redhat.com>
	<1120678946.12159.98.camel@prometheus.gamehouse.com>
	<20050706193651.GA27630@redhat.com>
Message-ID: <1120680130.26255.0.camel@prometheus.gamehouse.com>

On Wed, 2005-07-06 at 15:36 -0400, Dave Jones wrote:
> If your CPU supports NX, then the SMP kernel will use it, whereas
> the UP kernel will use segment limits, and disable sysenter support.
> If it doesn't support NX, there's no particular benefit.

Do Athlon64 3200+ (original, not newcastle) support NX?

-- 
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



From perbj at stanford.edu  Wed Jul  6 19:55:47 2005
From: perbj at stanford.edu (Per Bjornsson)
Date: Wed, 06 Jul 2005 12:55:47 -0700
Subject: rawhide report: 20050706 changes
In-Reply-To: <20050706171725.GB1942@redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com>  <20050706171725.GB1942@redhat.com>
Message-ID: <1120679747.2898.32.camel@localhost.localdomain>

On Wed, 2005-07-06 at 13:17 -0400, Dave Jones wrote:
> One change that might happen though -- there are newer CPUs that
> have (or will have soon) NX capability, but aren't SMP.
> (VIA have a chip ready, Intel are alleged to be putting NX in their
>  next line of laptop processors, probably AMD too).

Actually, the socket 754 AMD Semprons appear to be in this category too:
they support NX and are 32-bit. These appear to be all mobile Semprons
and desktop chips with model numbers >=3100+. And they are shipping,
most likely in significantly higher quantity than the VIA processors.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From alan at redhat.com  Wed Jul  6 20:17:39 2005
From: alan at redhat.com (Alan Cox)
Date: Wed, 6 Jul 2005 16:17:39 -0400
Subject: Window Placement
In-Reply-To: <42CC2A8F.4000109@gmail.com>
References: <42CC2A8F.4000109@gmail.com>
Message-ID: <20050706201739.GA18192@devserv.devel.redhat.com>

On Wed, Jul 06, 2005 at 03:01:35PM -0400, Emily Brantley wrote:
> Does the "best-fit" window placement algorithm annoy anyone else ?

And the window handling, the lack of panel overlap prevention, the 
poor handling of oversized windows and ... ;)

> possible all the way up in the top-left corner.  Placing windows
> perfectly atop one another seems broken.

People have tried different algorithms - including under the mouse. Early
wm's often stuck the new window to the mouse so you placed it yourself. 
Try a few window managers and see




From arjanv at redhat.com  Wed Jul  6 20:32:46 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 06 Jul 2005 22:32:46 +0200
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120680130.26255.0.camel@prometheus.gamehouse.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
	<20050706185653.GA25242@redhat.com>
	<1120678946.12159.98.camel@prometheus.gamehouse.com>
	<20050706193651.GA27630@redhat.com>
	<1120680130.26255.0.camel@prometheus.gamehouse.com>
Message-ID: <1120681966.4537.36.camel@laptopd505.fenrus.org>

On Wed, 2005-07-06 at 13:02 -0700, Jesse Keating wrote:
> On Wed, 2005-07-06 at 15:36 -0400, Dave Jones wrote:
> > If your CPU supports NX, then the SMP kernel will use it, whereas
> > the UP kernel will use segment limits, and disable sysenter support.
> > If it doesn't support NX, there's no particular benefit.
> 
> Do Athlon64 3200+ (original, not newcastle) support NX?

if it does it has "nx" in the flags section in /proc/cpuinfo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/c3b2ba74/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Wed Jul  6 20:33:40 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 06 Jul 2005 22:33:40 +0200
Subject: [DejaVu-fonts] Re: weird representation for FFFD
In-Reply-To: <20050706201720.GA92809@stud.fit.vutbr.cz>
References: <42C00042.3010307@draigBrady.com>
	<1119882800.5260.141.camel@localhost.localdomain>
	<42C01D5C.6030107@draigBrady.com>
	<7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>
	<42CC0288.3050409@draigBrady.com>
	<1120669332.17357.7.camel@rousalka.dyndns.org>
	<20050706201720.GA92809@stud.fit.vutbr.cz>
Message-ID: <1120682021.18405.29.camel@rousalka.dyndns.org>

Le mercredi 06 juillet 2005 ? 22:17 +0200, David Jez a ?crit :
> > Well, Fedora already has its share of ugly fonts with wide unicode
> > coverage. As we're only talking about a single character here, that does
> > not seem too difficult to create (just add a black diamond to a question
> > mark), I'd suggest you just get it into dejavu and I'll get the new
> > dejavu version into Fedora Extras.
> > 
> > If you're quick it'll be available for users by early august.
>   As you wish...

James Cloos already proposed to work on it. I must say it's great to
have a reactive font project instead of packaging and installing scores
of incomplete/different/frozen fonts just to get good glyph coverage.

And I hope this thread will inspire more people on the CCd lists to work
through dejavu!

Regards, 

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/72e9503b/attachment.sig>

From koneko.em at gmail.com  Wed Jul  6 20:38:58 2005
From: koneko.em at gmail.com (Emily Brantley)
Date: Wed, 06 Jul 2005 16:38:58 -0400
Subject: Window Placement
In-Reply-To: <20050706201739.GA18192@devserv.devel.redhat.com>
References: <42CC2A8F.4000109@gmail.com>
	<20050706201739.GA18192@devserv.devel.redhat.com>
Message-ID: <42CC4162.8070708@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox wrote:
> On Wed, Jul 06, 2005 at 03:01:35PM -0400, Emily Brantley wrote:
> 
>>Does the "best-fit" window placement algorithm annoy anyone else ?
> 
> 
> And the window handling, the lack of panel overlap prevention, the 
> poor handling of oversized windows and ... ;)

Oof, that's bad, but I run into those on a daily basis.

>>possible all the way up in the top-left corner.  Placing windows
>>perfectly atop one another seems broken.
> 
> 
> People have tried different algorithms - including under the mouse. Early
> wm's often stuck the new window to the mouse so you placed it yourself. 
> Try a few window managers and see
> 

I've always been partial to cascading windows.  Or randomized placement.
 Just ANY place but right on top of the last window.

I'm not the only one to notice this sort of thing.
http://mpt.net.nz/archive/2005/04/11/ubuntu (item 38)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCzEFgglUG+5Qgd5MRAjofAJ9oKxveeHKvHE7Nd+i6ft8a8XDesQCfcsVE
cNbYEZRPQ2ZSxt9XXNjMdP8=
=lQuD
-----END PGP SIGNATURE-----



From jkeating at j2solutions.net  Wed Jul  6 20:49:05 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 06 Jul 2005 13:49:05 -0700
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120681966.4537.36.camel@laptopd505.fenrus.org>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120651996.4537.13.camel@laptopd505.fenrus.org>
	<42CBCFE0.80107@redhat.com> <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
	<20050706185653.GA25242@redhat.com>
	<1120678946.12159.98.camel@prometheus.gamehouse.com>
	<20050706193651.GA27630@redhat.com>
	<1120680130.26255.0.camel@prometheus.gamehouse.com>
	<1120681966.4537.36.camel@laptopd505.fenrus.org>
Message-ID: <1120682945.26255.5.camel@prometheus.gamehouse.com>

On Wed, 2005-07-06 at 22:32 +0200, Arjan van de Ven wrote:
> if it does it has "nx" in the flags section in /proc/cpuinfo

Yes, it has NX.  Thanks.  I'll load up the SMP kernel.  Are there any
specific tests that could show a performance difference between up w/out
NX and SMP w/ NX (and those thing that are re-enabled w/ NX)?

-- 
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



From davej at redhat.com  Wed Jul  6 20:49:29 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 6 Jul 2005 16:49:29 -0400
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120682945.26255.5.camel@prometheus.gamehouse.com>
References: <20050706171725.GB1942@redhat.com>
	<1120673811.12159.92.camel@prometheus.gamehouse.com>
	<20050706182417.GA19696@redhat.com>
	<1120675864.12159.94.camel@prometheus.gamehouse.com>
	<20050706185653.GA25242@redhat.com>
	<1120678946.12159.98.camel@prometheus.gamehouse.com>
	<20050706193651.GA27630@redhat.com>
	<1120680130.26255.0.camel@prometheus.gamehouse.com>
	<1120681966.4537.36.camel@laptopd505.fenrus.org>
	<1120682945.26255.5.camel@prometheus.gamehouse.com>
Message-ID: <20050706204929.GB27630@redhat.com>

On Wed, Jul 06, 2005 at 01:49:05PM -0700, Jesse Keating wrote:
 > On Wed, 2005-07-06 at 22:32 +0200, Arjan van de Ven wrote:
 > > if it does it has "nx" in the flags section in /proc/cpuinfo
 > 
 > Yes, it has NX.  Thanks.  I'll load up the SMP kernel.  Are there any
 > specific tests that could show a performance difference between up w/out
 > NX and SMP w/ NX (and those thing that are re-enabled w/ NX)?

Any application which makes use of lots of syscalls should show
a noticable difference. Microbenchmarks have shown things like
context switching & pipe throughput also go up measurably when
sysenter is available.

		Dave



From lamont at gurulabs.com  Wed Jul  6 21:19:57 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Wed, 6 Jul 2005 15:19:57 -0600
Subject: rawhide report: 20050706 changes
In-Reply-To: <1120681966.4537.36.camel@laptopd505.fenrus.org>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<1120680130.26255.0.camel@prometheus.gamehouse.com>
	<1120681966.4537.36.camel@laptopd505.fenrus.org>
Message-ID: <200507061520.01885.lamont@gurulabs.com>

On Wednesday 06 July 2005 02:32pm, Arjan van de Ven wrote:
> On Wed, 2005-07-06 at 13:02 -0700, Jesse Keating wrote:
> > On Wed, 2005-07-06 at 15:36 -0400, Dave Jones wrote:
[SNIP]
> > Do Athlon64 3200+ (original, not newcastle) support NX?
>
> if it does it has "nx" in the flags section in /proc/cpuinfo

BTW:  I do trust the flags on AMD, but not on Intel.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050706/f250bd73/attachment.sig>

From casimiro.barreto at gmail.com  Thu Jul  7 03:05:17 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Thu, 07 Jul 2005 00:05:17 -0300
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <200507052010.24935.loony@loonybin.org>
References: <42CA8444.5050204@gmail.com>	<200507051742.25856.loony@loonybin.org>
	<42CB1D2E.10700@gmail.com> <200507052010.24935.loony@loonybin.org>
Message-ID: <42CC9BED.4060002@gmail.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/ea371b9c/attachment.htm>

From loony at loonybin.org  Thu Jul  7 03:12:25 2005
From: loony at loonybin.org (Peter Arremann)
Date: Wed, 6 Jul 2005 23:12:25 -0400
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <42CC9BED.4060002@gmail.com>
References: <42CA8444.5050204@gmail.com>
	<200507052010.24935.loony@loonybin.org>
	<42CC9BED.4060002@gmail.com>
Message-ID: <200507062312.25842.loony@loonybin.org>

On Wednesday 06 July 2005 23:05, Casimiro de Almeida Barreto wrote:
>  It seems that Solaris creates a partition (phisical) and them several (up
> to 8) slices... I gues that's where udf driver colapses.
Good - the slice you're trying to mount... what device is it mapped to? 
so instead of /dev/hdd1 as you tried to mount, try the /dev/hdd6 (or whatever 
the mapping ends up being, depending on how many partitions you made and how 
many slices you created in your solaris install) 

Peter.



From buildsys at redhat.com  Thu Jul  7 11:27:45 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 7 Jul 2005 07:27:45 -0400
Subject: rawhide report: 20050707 changes
Message-ID: <200507071127.j67BRj8Y023793@porkchop.devel.redhat.com>

 

 
Updated Packages:

awesfx-0.5.0d-3
---------------
* Wed Jul 06 2005 Karsten Hopp <karsten at redhat.de> 0.5.0d-3
- BuildRequires alsa-lib-devel

cairo-0.5.1-5
-------------
* Wed Jul 06 2005 Kristian H??gsberg <krh at redhat.com> - 0.5.1-5
- Fix typo in use of libpixman_version macro (Thanks to Michael
  Schwendt, #162550).

cdicconf-0.2-12
---------------
* Wed Jul 06 2005 Karsten Hopp <karsten at redhat.de> 0.2-12
- BuildRequires gtk+-devel for gtk-config
- BuildRequires libglade-devel for libglade-config

dump-0.4b40-4
-------------
* Wed Jul 06 2005 Karsten Hopp <karsten at redhat.de> 0.4b40-4
- BuildRequires ncurses-devel

eclipse-bugzilla-1:0.1.1_fc-1
-----------------------------
* Wed Jul 06 2005 Jeff Pound <jpound at redhat.com> 0.1.1_fc-1
- Integrate Apply Patch functionality.
- Various minor UI adjustments.

eclipse-cdt-1:3.0.0_fc-0.M7.1
-----------------------------
* Wed Jun 22 2005 Andrew Overholt <overholt at redhat.com> 3.0.0_fc-0.M7.1
- Import new upstream version (3.0M7).
- Remove refactoring/build.properties patch (now unneeeded).

kernel-2.6.12-1.1422_FC5
------------------------
* Wed Jul 06 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc2

nkf-2.05-1
----------
* Thu Jul 07 2005 Akira TAGOH <tagoh at redhat.com> - 2.05-1
- New upstream release.

pygtk2-2.6.2-1
--------------
* Wed Jul 06 2005 John (J5) Palmieri <johnp at redhat.com> - 2.6.2-1
- update to upstream 2.6.2
- remove gcc4 patch as it is in updated tarball

rhpl-0.169-1
------------
* Wed Jul 06 2005 Chris Lumens <clumens at redhat.com> 0.169-1
- Fix ppc64 requires. (katzj)
- Handle uncompressed .mo files as well.

selinux-policy-strict-1.25.1-3
------------------------------
* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-3
- Add boolean to allow sysadm_t to ptrace

* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-1
- Update to NSA
- Fix strict policy audit_write so you can login

* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.24-5
- Add winbind_helper_t

selinux-policy-targeted-1.25.1-3
--------------------------------
* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-3
- Add boolean to allow sysadm_t to ptrace

* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-1
- Update to NSA
- Fix strict policy audit_write so you can login

* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.24-5
- Add winbind_helper_t

Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	firstboot - 1.3.42-1.noarch requires system-config-display
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0



Broken deps for ppc
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for i386
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	rgmanager - 1.9.31-3.ia64 requires ccs
	jessie - 1.0.0-8.noarch requires java >= 0:1.4



Broken deps for s390x
----------------------------------------------------------
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	selinux-policy-targeted-sources - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	selinux-policy-strict - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-strict-sources - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	selinux-policy-targeted - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging



Broken deps for s390
----------------------------------------------------------
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl
	wsdl4j - 1.5.1-1jpp_1fc.noarch requires java
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires jta >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires java >= 0:1.4.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jta
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires java
	selinux-policy-targeted-sources - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	castor - 0.9.5-1jpp_1fc.noarch requires jta
	selinux-policy-targeted - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	selinux-policy-strict - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jessie - 1.0.0-8.noarch requires java >= 0:1.4
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict-sources - 1.25.1-3.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging





From aportal at univ-montp2.fr  Thu Jul  7 12:01:43 2005
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Thu, 7 Jul 2005 14:01:43 +0200
Subject: LDP man-pages
In-Reply-To: <200507011259.14645.aportal@univ-montp2.fr>
References: <200507011259.14645.aportal@univ-montp2.fr>
Message-ID: <200507071401.45582.aportal@univ-montp2.fr>

Le Vendredi 01 Juillet 2005 12:59, Alain PORTAL a ?crit :

> I'm really surprised to see that the man-pages package in FC4 is the same
> release than FC3, i.e. 1.67.
>
> Is there any reason for not providing the latest release avaliable?

Do I have to understand that nobody needs man-pages?
-- 
Les pages de manuel Linux en fran?ais :
http://manpagesfr.free.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/b9e6d34e/attachment.sig>

From fedora at camperquake.de  Thu Jul  7 12:08:34 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 7 Jul 2005 14:08:34 +0200
Subject: LDP man-pages
In-Reply-To: <200507071401.45582.aportal@univ-montp2.fr>
References: <200507011259.14645.aportal@univ-montp2.fr>
	<200507071401.45582.aportal@univ-montp2.fr>
Message-ID: <20050707140834.6462e48d@nausicaa.camperquake.de>

Hi.

Alain PORTAL <aportal at univ-montp2.fr> wrote:

> Do I have to understand that nobody needs man-pages?

Well, given my experience with people nobody seems to read them :)


-- 
If there is a hell
I'm sure this is how it smells
Wish this were a dream, but no, it isn't
                                      -- Tim Jensen/Yoko Kanno "Rain"



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Thu Jul  7 12:23:41 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 7 Jul 2005 14:23:41 +0200
Subject: LDP man-pages
In-Reply-To: <200507011259.14645.aportal@univ-montp2.fr>
References: <200507011259.14645.aportal@univ-montp2.fr>
Message-ID: <20050707142341.7d2960b0@python2>

Alain PORTAL wrote :

> Hi,
> 
> I'm really surprised to see that the man-pages package in FC4 is the same 
> release than FC3, i.e. 1.67.
> 
> Is there any reason for not providing the latest release avaliable?

The update to the latest version (2.05) did happen, but too late for
inclusion into FC4 :

* Mon Jul 04 2005 Jiri Ryska <jryska at redhat....> 2.05-1
- update to 2.05
- atanh(3) fix
- issue(5) fix
- ldd(1) fix
- removed man1p/{compress,uncompress,renice}.1p

You can get it from development, and should probably install just fine on
FC3 and FC4.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3
Load : 0.47 0.86 0.89



From aportal at univ-montp2.fr  Thu Jul  7 12:32:13 2005
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Thu, 7 Jul 2005 14:32:13 +0200
Subject: LDP man-pages
In-Reply-To: <20050707140834.6462e48d@nausicaa.camperquake.de>
References: <200507011259.14645.aportal@univ-montp2.fr>
	<200507071401.45582.aportal@univ-montp2.fr>
	<20050707140834.6462e48d@nausicaa.camperquake.de>
Message-ID: <200507071432.15456.aportal@univ-montp2.fr>

Le Jeudi 07 Juillet 2005 14:08, Ralf Ertzinger a ?crit :

> Well, given my experience with people nobody seems to read them :)

Not right, I often read them, and not only to translate them :-)
Who knows the whole options for cp, rm, find, grep, etc. ?
Not me.

Yours sincerely,
Alain
-- 
Les pages de manuel Linux en fran?ais :
http://manpagesfr.free.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/b9e1f548/attachment.sig>

From aportal at univ-montp2.fr  Thu Jul  7 12:42:23 2005
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Thu, 7 Jul 2005 14:42:23 +0200
Subject: LDP man-pages
In-Reply-To: <20050707142341.7d2960b0@python2>
References: <200507011259.14645.aportal@univ-montp2.fr>
	<20050707142341.7d2960b0@python2>
Message-ID: <200507071442.25688.aportal@univ-montp2.fr>

Le Jeudi 07 Juillet 2005 14:23, Matthias Saou a ?crit :
> Alain PORTAL wrote :
> > Hi,
> >
> > I'm really surprised to see that the man-pages package in FC4 is the same
> > release than FC3, i.e. 1.67.
> >
> > Is there any reason for not providing the latest release avaliable?
>
> The update to the latest version (2.05) did happen, but too late for
> inclusion into FC4 :

That's right for the 2.05, but there were 8 versions between 1.67 and 2.05 
(1.68, 1.69, 1.70, 2.00, 2.01, 2.02, 2.03, 2.04)

> * Mon Jul 04 2005 Jiri Ryska <jryska at redhat....> 2.05-1
> - update to 2.05
> - atanh(3) fix
> - issue(5) fix
> - ldd(1) fix
> - removed man1p/{compress,uncompress,renice}.1p

Sorry, I haven't seen this build report.

And what about the French man-pages package that is near 3 years old?

Yours sincerely,
Alain
-- 
Les pages de manuel Linux en fran?ais :
http://manpagesfr.free.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/0b94b081/attachment.sig>

From dragoran at feuerpokemon.de  Thu Jul  7 13:03:16 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Thu, 07 Jul 2005 15:03:16 +0200
Subject: kernel ignores pci device
In-Reply-To: <42CA5D16.7050104@feuerpokemon.de>
References: <42CA5D16.7050104@feuerpokemon.de>
Message-ID: <42CD2814.7080001@feuerpokemon.de>

dragoran wrote:

> I have a tvcard with a saa7134 chip which worked find in fc4 i386.
> now running on amd64 I get during boot:
> PCI: device 0000:02:08.0 has unknown header type 7f, ignoring.
> and can't see it in lspci.
> I am using kernel-2.6.12-1.1387_FC4
> Should I fill a bug?
> Or is something missconfigured?
>
I have openedthe case;removed the tvcard;repluged it and it works now



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Thu Jul  7 13:59:26 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 7 Jul 2005 15:59:26 +0200
Subject: LDP man-pages
In-Reply-To: <200507071442.25688.aportal@univ-montp2.fr>
References: <200507011259.14645.aportal@univ-montp2.fr>
	<20050707142341.7d2960b0@python2>
	<200507071442.25688.aportal@univ-montp2.fr>
Message-ID: <20050707155926.792d34fe@python2>

Alain PORTAL wrote :

> And what about the French man-pages package that is near 3 years old?

Bugzilla is your friend. Developers aren't continuously tracking new
versions of the software they're assigned maintainership of, and very
often a quick notification (or better, a spec file patch) is enough to get
the package updated.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3
Load : 0.84 0.64 0.43



From aportal at univ-montp2.fr  Thu Jul  7 14:29:42 2005
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Thu, 7 Jul 2005 16:29:42 +0200
Subject: LDP man-pages
In-Reply-To: <20050707155926.792d34fe@python2>
References: <200507011259.14645.aportal@univ-montp2.fr>
	<200507071442.25688.aportal@univ-montp2.fr>
	<20050707155926.792d34fe@python2>
Message-ID: <200507071629.44827.aportal@univ-montp2.fr>

Le Jeudi 07 Juillet 2005 15:59, Matthias Saou a ?crit :
> Alain PORTAL wrote :
> > And what about the French man-pages package that is near 3 years old?
>
> Bugzilla is your friend.

Yes, of course.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139695

> Developers aren't continuously tracking new 
> versions of the software they're assigned maintainership of, and very
> often a quick notification (or better, a spec file patch) is enough to get
> the package updated.

It seems to me that the packager have notifications enough since three weeks.

Yours sincerely,
Alain
-- 
Les pages de manuel Linux en fran?ais :
http://manpagesfr.free.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/4f4a7a5b/attachment.sig>

From mricon at gmail.com  Thu Jul  7 19:13:31 2005
From: mricon at gmail.com (Konstantin Ryabitsev)
Date: Thu, 7 Jul 2005 15:13:31 -0400
Subject: eclipse-pydev and bundled pylint
In-Reply-To: <1120678842.2662.40.camel@tower.toronto.redhat.com>
References: <200507061113.j66BDrg7018892@porkchop.devel.redhat.com>
	<f8f6300f0507060800640ce63e@mail.gmail.com>
	<1120678842.2662.40.camel@tower.toronto.redhat.com>
Message-ID: <f8f6300f050707121358e1e81a@mail.gmail.com>

On 06/07/05, Jeff Pound <jpound at redhat.com> wrote:
> The upstream Pydev project (http://pydev.sf.net) includes a few
> third-party packages including pylint. Using the system installed pylint
> would be ideal but it would require maintaining a forked version of
> pydev in sync with the upstream releases. If you think it's worthwhile
> to pursue, you should file a bug against the upstream pydev to have them
> use separate packages for third party apps, and have pydev configurable
> for these apps.

Hmm... well, it's actually not uncommon for projects to bundle various
libraries with the distribution, for various misguided "convenience"
reasons. Is it difficult to modify the package to let it make use of
the globally installed pylint? I mean, if Fedora is to ship pylint,
it's best to let it be globally available to other projects as well.

The same goes for pychecker, which is actually already in Core, so
there is already duplication between the two packages.

Regards,
-- 
Konstantin Ryabitsev
Zlotniks, INC

"???????? ?????????? ????? ? ??????? ???? ?????."



From rmy at tigress.co.uk  Thu Jul  7 20:51:44 2005
From: rmy at tigress.co.uk (Ron Yorston)
Date: Thu, 7 Jul 2005 21:51:44 +0100 (BST)
Subject: Window Placement
Message-ID: <200507072051.VAA21236@internal.tigress.co.uk>

Alan Cox wrote:
>People have tried different algorithms - including under the mouse. Early
>wm's often stuck the new window to the mouse so you placed it yourself. 
>Try a few window managers and see

Or try my patch to metacity which implements manual placement.  It's the
only way to go if you have multiple large displays.  RPMs for FC3 and FC4
are available.

   http://intgat.tigress.co.uk/rmy/metacity/index.html

There's another, unrelated patch for metacity (which I haven't tried) that
adds some different placement modes:

   http://home.uchicago.edu/~chad/metacity/

Ron



From ivazquez at ivazquez.net  Thu Jul  7 21:11:44 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Thu, 07 Jul 2005 17:11:44 -0400
Subject: Window Placement
In-Reply-To: <200507072051.VAA21236@internal.tigress.co.uk>
References: <200507072051.VAA21236@internal.tigress.co.uk>
Message-ID: <1120770704.9522.10.camel@ignacio.ignacio.lan>

On Thu, 2005-07-07 at 21:51 +0100, Ron Yorston wrote:
> Alan Cox wrote:
> >People have tried different algorithms - including under the mouse. Early
> >wm's often stuck the new window to the mouse so you placed it yourself. 
> >Try a few window managers and see
> 
> Or try my patch to metacity which implements manual placement.  It's the
> only way to go if you have multiple large displays.  RPMs for FC3 and FC4
> are available.
> 
>    http://intgat.tigress.co.uk/rmy/metacity/index.html

Mind if I put a package with this in my Alternatives repo?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/de830ed9/attachment.sig>

From koneko.em at gmail.com  Thu Jul  7 21:15:38 2005
From: koneko.em at gmail.com (Emily Brantley)
Date: Thu, 07 Jul 2005 17:15:38 -0400
Subject: Window Placement
In-Reply-To: <200507072051.VAA21236@internal.tigress.co.uk>
References: <200507072051.VAA21236@internal.tigress.co.uk>
Message-ID: <42CD9B7A.3030409@gmail.com>

Ron Yorston wrote:
> Or try my patch to metacity which implements manual placement.  It's the
> only way to go if you have multiple large displays.  RPMs for FC3 and FC4
> are available.

How does "manual" placement work ?  I don't think I've ever heard of it.

Em
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050707/c8faee48/attachment.sig>

From skvidal at phy.duke.edu  Thu Jul  7 21:20:25 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 07 Jul 2005 17:20:25 -0400
Subject: Window Placement
In-Reply-To: <42CD9B7A.3030409@gmail.com>
References: <200507072051.VAA21236@internal.tigress.co.uk>
	<42CD9B7A.3030409@gmail.com>
Message-ID: <1120771225.5121.26.camel@cutter>

On Thu, 2005-07-07 at 17:15 -0400, Emily Brantley wrote:
> Ron Yorston wrote:
> > Or try my patch to metacity which implements manual placement.  It's the
> > only way to go if you have multiple large displays.  RPMs for FC3 and FC4
> > are available.
> 
> How does "manual" placement work ?  I don't think I've ever heard of it.
> 

each new window attaches to the mouse pointer and is placed wherever you
click.

-sv




From rmy at tigress.co.uk  Thu Jul  7 21:18:22 2005
From: rmy at tigress.co.uk (Ron Yorston)
Date: Thu, 7 Jul 2005 22:18:22 +0100 (BST)
Subject: Window Placement
Message-ID: <200507072118.WAA21303@internal.tigress.co.uk>

Ignacio Vazquez-Abrams <ivazquez at ivazquez.net> wrote:
>On Thu, 2005-07-07 at 21:51 +0100, Ron Yorston wrote:
>> Alan Cox wrote:
>> >People have tried different algorithms - including under the mouse. Earl=
>y
>> >wm's often stuck the new window to the mouse so you placed it yourself.=20
>> >Try a few window managers and see
>>=20
>> Or try my patch to metacity which implements manual placement.  It's the
>> only way to go if you have multiple large displays.  RPMs for FC3 and FC4
>> are available.
>>=20
>>    http://intgat.tigress.co.uk/rmy/metacity/index.html
>
>Mind if I put a package with this in my Alternatives repo?

Not at all.  Help yourself.

Ron



From buildsys at redhat.com  Fri Jul  8 11:16:22 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 8 Jul 2005 07:16:22 -0400
Subject: rawhide report: 20050708 changes
Message-ID: <200507081116.j68BGMeC019595@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-10.3.0.4-1
-------------------
* Thu Jul 07 2005 Paul Nasrat <pnasrat at redhat.com> 10.3.0.4-1
- Select kernel-devel (katzj #160533)
- Fixups for ia64 images from prarit (katzj #162072)
- Include yum libraries in stage2
- Remove gzread.py (clumens)

audit-0.9.16-1
--------------
* Thu Jul 07 2005 Steve Grubb <sgrubb at redhat.com> 0.9.16-1
- Adjust umask
- Adjust length of strings for file system watches to not include NUL
- Remove extra error message from audit_send

checkpolicy-1.25.2-1
--------------------
* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-1
- Update to NSA Release
	* Merged loadable module support from Tresys Technology.
	* Merged patch to prohibit the use of * and ~ in type sets 
	  (other than in neverallow statements) and in role sets
	  from Joshua Brindle (Tresys).
	* Updated version for release.

firstboot-1.3.43-1
------------------
* Thu Jul 07 2005 Chris Lumens <clumens at redhat.com> 1.3.43-1
- Remove dependancy on xsri (#145807).
- Fix typo in "additional" (#158435).
- Tabs vs. spaces consistency (#156456).
- Don't require system-config-display on ppc64.

fonts-KOI8-R-1.0-8
------------------
* Thu Jul 07 2005 Karsten Hopp <karsten at redhat.de> 1.0-8
- BuildRequires xorg-x11-font-utils for bdftopcf and mkfontdir

freetype-2.1.9-3
----------------
* Thu Jul 07 2005 Karsten Hopp <karsten at redhat.de> 2.1.9-3
- BuildRequires xorg-x11-devel

g-wrap-1.3.4-9
--------------
* Thu Jul 07 2005 Bill Nottingham <notting at redhat.com> 1.3.4-9
- add patch for M4 quoting (#162649, <rc040203 at freenet.de>)

gaim-1:1.4.0-1.fc5
------------------
* Thu Jul 07 2005 Warren Togami <wtogami at redhat.com> 1:1.4.0-1
- 1.4.0

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_33rh
------------------------------------------
* Thu Jul 07 2005 Gary Benson <gbenson at redhat.com>  0:1.4.2.0-40jpp_33rh
- Bootstrap onto ia64, ppc64, s390 and s390x.
- Add python dependency for aot-compile-rpm.

* Thu Jul 07 2005 Gary Benson <gbenson at redhat.com>  0:1.4.2.0-40jpp_32rh
- Import java-gcj-compat 1.0.31.
- Move the aot-compile scripts to the devel subpackage.

* Mon Jun 06 2005 Thomas Fitzsimmons <fitzsim at redhat.com> 0:1.4.2.0-40jpp_31rh
- Add jaxp_parser_impl.jar alternative. (#158751)
- Separate post and postun requires lines.
- Use gij, not gcj to compute version strings in post and triggerin sections.

kdevelop-9:3.2.1-3
------------------
* Thu Jul 07 2005 Than Ngo <than at redhat.com> 8:3.2.1-3
- fix uninitialized variable warning #162367

libsepol-1.7-2
--------------
* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.7-2
- Remove genpolbools and genpoluser

* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.7-1
- Upgrade to latest from NSA
	* Merged loadable module support from Tresys Technology.

numactl-0.6.4-1.23
------------------
* Thu Jul 07 2005 Dave Jones <davej at redhat.com>
- numactl doesn't own the manpage dirs. (#161547)

openoffice.org-1:1.9.115-1.2.0.fc5
----------------------------------
* Thu Jul 07 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.115-1
- bump to next version
- add openoffice.org-1.9.115.ooo51673.printing.checkerror.patch
- rpath of ORIGIN complete, enable failure on regression
- drop integrated openoffice.org-1.9.114.ooo50745.cruxcrash.vcl.patch

* Mon Jul 04 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.114-2
- further split langpacks
- modify test for $ORIGIN rpaths
- rh#161886# 
    + openoffice.org-1.9.114.oooXXXXX.rpath.patch
    + openoffice.org-1.9.114.rh161886.rpath.desktop.patch
- add openoffice.org-1.9.114.ooo50745.cruxcrash.vcl.patch for rh#160293#
- add openoffice.org-1.9.114.ooo51637.solenv.pyuno.patch to workaround
  multiple pyuno registering failures
- add openoffice.org-1.9.114.ooo51638.mailmerge.patch to provide email
  support for maill merge
- add openoffice.org-1.9.114.oooXXXXX.nostlport.patch and not build
  stlport

redhat-artwork-0.125-1
----------------------
* Thu Jul 07 2005 John (J5) Palmieri <johnp at redhat.com> 0.125-1
- upgrade to 0.125 which adds diana's new icons and cursors

selinux-policy-strict-1.25.1-6
------------------------------
* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-6
- Fixes for winbind

* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-5
- Allow cgi script to append to httpd_log_t
- More fixes for samba net command

* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-4
- Add boolean to allow sysadm_t to ptrace

selinux-policy-targeted-1.25.1-6
--------------------------------
* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-6
- Fixes for winbind

* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-5
- Allow cgi script to append to httpd_log_t
- More fixes for samba net command

* Wed Jul 06 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-4
- Add boolean to allow sysadm_t to ptrace

squid-7:2.5.STABLE10-1
----------------------
* Thu Jul 07 2005 Martin Stransky <stransky at redhat.com> 7:2.5.STABLE10-1
- new upstream version
- enabled fakeauth utility (#154020)
- enabled digest authentication scheme (#155882)
- all error pages marked as config (#127836)
- patch for 64bit statvfs interface (#153274)
- added httpd config file for cachemgr.cgi (#112725)

system-config-nfs-1.3.11-1
--------------------------
* Thu Jul 07 2005 Nils Philippsen <nphilipp at redhat.com> 1.3.11
- display permissions correctly in list (#162437)
- use symbolic names when dealing with list columns
- edit entry when double-clicking on it

tcsh-6.14-3
-----------
* Thu Jul 07 2005 Miloslav Trmac <mitr at redhat.com> - 6.14-3
- Fix -n (#162187)

xmlsec1-1.2.8-1
---------------
* Fri Jul 08 2005 Daniel Veillard <veillard at redhat.com> 1.2.8-1
- update from upstream, needed for openoffice

zlib-1.2.2.2-4
--------------
* Thu Jul 07 2005 Ivana Varekova <varekova at redhat.com> 1.2.2.2-4
- fix bug 162392 - CAN-2005-2096

Broken deps for i386
----------------------------------------------------------
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	selinux-policy-targeted - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_33rh.s390 requires gjdoc
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2



Broken deps for ia64
----------------------------------------------------------
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	rgmanager - 1.9.31-3.ia64 requires ccs
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_33rh.ia64 requires gjdoc
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16



Broken deps for ppc64
----------------------------------------------------------
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_33rh.ppc64 requires gjdoc
	firstboot - 1.3.43-1.noarch requires system-config-display
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_33rh.s390x requires gjdoc
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11





From tarjei.knapstad at predichem.com  Fri Jul  8 11:57:09 2005
From: tarjei.knapstad at predichem.com (Tarjei Knapstad)
Date: Fri, 08 Jul 2005 13:57:09 +0200
Subject: rawhide report: 20050708 changes
In-Reply-To: <200507081116.j68BGMeC019595@porkchop.devel.redhat.com>
References: <200507081116.j68BGMeC019595@porkchop.devel.redhat.com>
Message-ID: <1120823829.17450.231.camel@tarjei.predichem.nett>

On Fri, 2005-07-08 at 13:16, Build System wrote:

> Broken deps for i386
> ----------------------------------------------------------
> 	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
> 	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
(...)

Wouldn't it be possible to have the build system automatically rebuild
all the kernel modules against updated kernels? (should be easy given
the package naming convention for kernel modules...?)

--
Tarjei



From casimiro.barreto at gmail.com  Fri Jul  8 16:18:05 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 08 Jul 2005 13:18:05 -0300
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <200507062312.25842.loony@loonybin.org>
References: <42CA8444.5050204@gmail.com>	<200507052010.24935.loony@loonybin.org>	<42CC9BED.4060002@gmail.com>
	<200507062312.25842.loony@loonybin.org>
Message-ID: <42CEA73D.5010603@gmail.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050708/45e8bc64/attachment.htm>

From drepper at redhat.com  Fri Jul  8 17:01:12 2005
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 08 Jul 2005 10:01:12 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
Message-ID: <42CEB158.9080308@redhat.com>

Tomorrows glibc will contain the last act of the LinuxThreads saga: its
total demise.  It's gone for good.

By the time FC5 will hit the street people had more than three years
time to adapt their code to NPTL.  In the last year we've hardly heard
about any problem related to LT vs NPTL and the F4 switch to default to
linking with NPTL also didn't cause any problems we know of.

So, that's it then.  LT is really gone for good.  It is not possible to
resurrect it as an optional add-on or so.  The trunk glibc used in
rawhide and FC5 is already diverging so that in a couple of days (when
we make our usual adjustments to the build environment) almost no
application will run with LT.

Another change caused by this is that it is not possible anymore to use
custom kernels which don't have NPTL support.  I.e., no kernels before
2.6 (or 2.4 with NPTL backport) can be used ever again.  I don't think
this should be a problem since nobody running such old kernels should
update the userlevel code but people do stupid things so I thought I
mention it.

Those who really need LT for whatever reason have two options:

1. Don't update.  Or at least keep a FC4 partition around.

2. Use Xen with a FC4 guest domain.  For x86-64 and ppc this should also
   be possible in the not too distant future.


I hope everybody who's updating their FC installation from rawhide daily
is reading this.  It makes no sense whining about this here or anywhere
else.  LT is discontinued upstream, the same changes apply to all
distributions.  The good thing is that the spreading of misinformation
about LD_ASSUME_KERNEL is coming to an end.  That envvar is still there
and can cause havoc but it cannot do anything useful anymore (for now).
 If somebody has scripts or macros which automatically set this envvar,
you better adjust all that code.

As usual, be careful with glibc updates.  Especially this one for the
aforementioned reasons and because implementing these changes required
substantial modification of the build process.  It's simpler now but
obviously not as well tested.

-- 
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050708/d74a6ba2/attachment.sig>

From fedora at camperquake.de  Fri Jul  8 19:24:57 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 8 Jul 2005 21:24:57 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <42CEB158.9080308@redhat.com>
References: <42CEB158.9080308@redhat.com>
Message-ID: <20050708212457.61f78e39@nausicaa.camperquake.de>

Hi.

Ulrich Drepper <drepper at redhat.com> wrote:

> Tomorrows glibc will contain the last act of the LinuxThreads saga: its
> total demise.  It's gone for good.

Thanks for the head up. I am running rawhide, but have one application
that uses LT and that has to work for another month or so (Matlab R13).

So glibc will have to be excluded from the update frenzy :)

-- 
The only "intuitive" interface is the nipple. After that, it's all
learned.  -- Bruce Ediger, bediger at teal.csn.org, in comp.os.linux.misc



From jakub at redhat.com  Fri Jul  8 19:54:05 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Fri, 8 Jul 2005 15:54:05 -0400
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <20050708212457.61f78e39@nausicaa.camperquake.de>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
Message-ID: <20050708195404.GB4884@devserv.devel.redhat.com>

On Fri, Jul 08, 2005 at 09:24:57PM +0200, Ralf Ertzinger wrote:
> Ulrich Drepper <drepper at redhat.com> wrote:
> 
> > Tomorrows glibc will contain the last act of the LinuxThreads saga: its
> > total demise.  It's gone for good.
> 
> Thanks for the head up. I am running rawhide, but have one application
> that uses LT and that has to work for another month or so (Matlab R13).
> 
> So glibc will have to be excluded from the update frenzy :)

There will be a mass rebuild of all packages hopefully soon, and once
that is done, all packages will require that glibc.  So at that point
you'll need to stop updating altogether or give up apps that rely on
LinuxThreads.

	Jakub



From tibbs at math.uh.edu  Fri Jul  8 19:57:43 2005
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Fri, 08 Jul 2005 14:57:43 -0500
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <20050708212457.61f78e39@nausicaa.camperquake.de> (Ralf
	Ertzinger's message of "Fri, 8 Jul 2005 21:24:57 +0200")
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
Message-ID: <ufau0j55avc.fsf@epithumia.math.uh.edu>

>>>>> "RE" == Ralf Ertzinger <fedora at camperquake.de> writes:

RE> Thanks for the head up. I am running rawhide, but have one
RE> application that uses LT and that has to work for another month or
RE> so (Matlab R13).

How do you determine whether or not a particular application uses the
old threading model?  ldd on an old Matlab R13 binary shows:

        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00116000)

but R14sp2 shows essentially the same thing:

        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0015e000)

and I'm sure there would have been complaints if the Fedora had
broken the latest version of Matlab.  (Unfortunately Matlab is the
crappiest piece of software that I have no choice but to keep
running, and always causes a number of problems.)

 - J<



From fedora at camperquake.de  Fri Jul  8 20:01:14 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 8 Jul 2005 22:01:14 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <ufau0j55avc.fsf@epithumia.math.uh.edu>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu>
Message-ID: <20050708220114.6c8bbfcb@nausicaa.camperquake.de>

Hi.

Jason L Tibbitts III <tibbs at math.uh.edu> wrote:

> How do you determine whether or not a particular application uses the
> old threading model?  ldd on an old Matlab R13 binary shows:

Oh, that was easy. After a certain glibc update it did no
longer work :)

Reading the changelog entry showed the reason and a workaround.

-- 
Q. How can you tell when a violist is playing out of tune?
A. The bow is moving.



From fedora at camperquake.de  Fri Jul  8 20:04:29 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 8 Jul 2005 22:04:29 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <20050708220114.6c8bbfcb@nausicaa.camperquake.de>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu>
	<20050708220114.6c8bbfcb@nausicaa.camperquake.de>
Message-ID: <20050708220429.5c941758@nausicaa.camperquake.de>

Hi.

Ralf Ertzinger <fedora at camperquake.de> wrote:

> Oh, that was easy. After a certain glibc update it did no
> longer work :)

Speaking of which, with my current setup (glibc-2.3.5-10
kernel-2.6.12-1.1411_FC5) it works again without setting
magical environment variables.

Go figure.

-- 
"Did they buy it?"
"I don't think they bought it."
"Of course they bought it."
"Shhh, they're looking this way, remember to keep a straight face..." 



From drepper at redhat.com  Fri Jul  8 20:03:43 2005
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 08 Jul 2005 13:03:43 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <20050708212457.61f78e39@nausicaa.camperquake.de>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
Message-ID: <42CEDC1F.2030508@redhat.com>

Ralf Ertzinger wrote:
> So glibc will have to be excluded from the update frenzy :)

As I said, in a couple of days we'll hopefully have the gcc, binutils,
glibc pieces in place to make the next big change in the build
procedures and then you cannot do *any* update unless you get the new
glibc.  The rpm infrastructure should catch those requirements but be
warned.  We'll announce the build changes ahead of time as well.

-- 
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050708/353a981b/attachment.sig>

From rms at 1407.org  Fri Jul  8 20:02:18 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 08 Jul 2005 21:02:18 +0100
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <ufau0j55avc.fsf@epithumia.math.uh.edu>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu>
Message-ID: <1120852938.2783.5.camel@roque>

On Fri, 2005-07-08 at 14:57 -0500, Jason L Tibbitts III wrote:
> and I'm sure there would have been complaints if the Fedora had
> broken the latest version of Matlab.  (Unfortunately Matlab is the
> crappiest piece of software that I have no choice but to keep
> running, and always causes a number of problems.)

Are you absolutely fscking sure you need Matlab at all?

Have you really checked deeply into octave?

Cheers,

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050708/00afb3ee/attachment.sig>

From skvidal at phy.duke.edu  Fri Jul  8 20:37:44 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 08 Jul 2005 16:37:44 -0400
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120852938.2783.5.camel@roque>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu> <1120852938.2783.5.camel@roque>
Message-ID: <1120855064.18557.61.camel@cutter>

On Fri, 2005-07-08 at 21:02 +0100, Rui Miguel Seabra wrote:
> On Fri, 2005-07-08 at 14:57 -0500, Jason L Tibbitts III wrote:
> > and I'm sure there would have been complaints if the Fedora had
> > broken the latest version of Matlab.  (Unfortunately Matlab is the
> > crappiest piece of software that I have no choice but to keep
> > running, and always causes a number of problems.)
> 
> Are you absolutely fscking sure you need Matlab at all?
> 
> Have you really checked deeply into octave?
> 

in our case it's the toolkits. We've pushed octave in places where it
can be used. It is very nice. But interfacing to some devices is really
only do-able with matlab.

-sv




From fedora at camperquake.de  Fri Jul  8 20:40:52 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 8 Jul 2005 22:40:52 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120852938.2783.5.camel@roque>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu>
	<1120852938.2783.5.camel@roque>
Message-ID: <20050708224052.7e441c82@nausicaa.camperquake.de>

Hi.

Rui Miguel Seabra <rms at 1407.org> wrote:

> Are you absolutely fscking sure you need Matlab at all?

I am two, maybe three weeks from the end of my diploma
thesis, and I am not really going to change the underlying
software right now :)

So, the answer would be: yes, I am absolutely fscking sure.

-- 
I have seen slower people than I am -- and even quieter, and more
listless, and lazier people than I am. But they were dead.
		-- Mark Twain



From ed at eh3.com  Fri Jul  8 21:10:58 2005
From: ed at eh3.com (Ed Hill)
Date: Fri, 08 Jul 2005 17:10:58 -0400
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120852938.2783.5.camel@roque>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu> <1120852938.2783.5.camel@roque>
Message-ID: <1120857058.13579.22.camel@ernie>

On Fri, 2005-07-08 at 21:02 +0100, Rui Miguel Seabra wrote:
> 
> Are you absolutely fscking sure you need Matlab at all?


Hi Rui,

Octave is very nice but it still lags MatLAB in a few key areas such as
the generation of figures.  Also, you might find that people are just a
little more receptive to your suggestions when you leave out expressions
such as "absolutely fscking sure" which can be interpreted as something
other than good-natured humor.

Of course, *I* interpret it as good-natured humor but then not everyone
is as wildly optimistic...  ;-)

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464



From loony at loonybin.org  Fri Jul  8 22:57:37 2005
From: loony at loonybin.org (Peter Arremann)
Date: Fri, 8 Jul 2005 18:57:37 -0400
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <42CEA73D.5010603@gmail.com>
References: <42CA8444.5050204@gmail.com>
	<200507062312.25842.loony@loonybin.org>
	<42CEA73D.5010603@gmail.com>
Message-ID: <200507081857.38050.loony@loonybin.org>

On Friday 08 July 2005 12:18, Casimiro de Almeida Barreto wrote:
>  Thanks, now it is working !!!

Good :-) One word of advice though - I tried this out myself the other day, 
ran journaling ufs, crashed my sol 10 install, booted into linux and tried 
mounting the partition then *grins* total screwup... Reproduced it a second 
time the same way too... seems that if there is stuff in the journal and you 
mount the filesystem in linux, you can loose your data...

Peter.



From rms at 1407.org  Sat Jul  9 01:20:04 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Sat, 09 Jul 2005 02:20:04 +0100
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120857058.13579.22.camel@ernie>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu> <1120852938.2783.5.camel@roque>
	<1120857058.13579.22.camel@ernie>
Message-ID: <1120872004.2783.8.camel@roque>

On Fri, 2005-07-08 at 17:10 -0400, Ed Hill wrote:
> On Fri, 2005-07-08 at 21:02 +0100, Rui Miguel Seabra wrote:
> > 
> > Are you absolutely fscking sure you need Matlab at all?
> 
> 
> Hi Rui,
> 
> Octave is very nice but it still lags MatLAB in a few key areas such as
> the generation of figures.  Also, you might find that people are just a
> little more receptive to your suggestions when you leave out expressions
> such as "absolutely fscking sure" which can be interpreted as something
> other than good-natured humor.

Octave interacts directly with gnuplot, AFAIK, so maybe you could
elaborate on what you mean with figures?

> Of course, *I* interpret it as good-natured humor but then not everyone
> is as wildly optimistic...  ;-)

Kacl of doog-daturen rumoh is not an tequiremenr of eifl ;)

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050709/88743a1b/attachment.sig>

From casimiro.barreto at gmail.com  Sat Jul  9 01:39:48 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 08 Jul 2005 22:39:48 -0300
Subject: Is there a bug in UFS system (ufstype=sunx86)
In-Reply-To: <200507081857.38050.loony@loonybin.org>
References: <42CA8444.5050204@gmail.com>	<200507062312.25842.loony@loonybin.org>	<42CEA73D.5010603@gmail.com>
	<200507081857.38050.loony@loonybin.org>
Message-ID: <42CF2AE4.1030404@gmail.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050708/f23ee917/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3533 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050708/f23ee917/attachment.bin>

From ed at eh3.com  Sat Jul  9 02:12:24 2005
From: ed at eh3.com (Ed Hill)
Date: Fri, 08 Jul 2005 22:12:24 -0400
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120872004.2783.8.camel@roque>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu> <1120852938.2783.5.camel@roque>
	<1120857058.13579.22.camel@ernie>  <1120872004.2783.8.camel@roque>
Message-ID: <1120875145.13579.73.camel@ernie>

On Sat, 2005-07-09 at 02:20 +0100, Rui Miguel Seabra wrote:
> 
> Octave interacts directly with gnuplot, AFAIK, so maybe you could
> elaborate on what you mean with figures?

Hi Rui,

Please see:

  http://users.powernet.co.uk/kienzle/octave/
  http://users.powernet.co.uk/kienzle/octave/matcompat/

and notice how, for instance, shaded color plots such as:

  a = rand(20,20);
  surf(a), view(2), shading interp

are not readily produced in current octave versions.

And please understand that I do not in any way mean to belittle Octave.
Its a very useful and cool tool.  Its good stuff.  But its not a drop-in
replacement for many MatLAB uses.

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464



From buildsys at redhat.com  Sat Jul  9 11:18:53 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 9 Jul 2005 07:18:53 -0400
Subject: rawhide report: 20050709 changes
Message-ID: <200507091118.j69BIrwV008443@porkchop.devel.redhat.com>

 

 
Updated Packages:

control-center-1:2.11.5-1
-------------------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> - 1:2.11.5-1
- Update to 2.11.5

dhcp-10:3.0.2-14.FC5
--------------------
* Fri Jul 08 2005 Jason Vas Dias <jvdias at redhat.com> 10:3.0.2-14.FC5
- Allow package to compile with glibc-headers-2.3.5-11 (tr.c's use of __u16)

eclipse-bugzilla-1:0.1.1_fc-2
-----------------------------
* Fri Jul 08 2005 Jeff Pound <jpound at redhat.com> 0.1.1_fc-2
- Fix eclipse build specification to be arch independant.

eog-2.11.0-1
------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> 2.11.0-1
- Update to 2.11.0

gdb-6.3.0.0-1.37
----------------
* Fri Jul 08 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.37
- Bump up release number.

* Fri Jul 08 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.35
- Build pseudo-registers properly for sigtramp frame.
- Bugzilla 160339

* Fri Jul 08 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.34
- Bump up release number.

glib2-2.7.2-1
-------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> - 2.7.2-1
- Update to 2.7.2

glibc-2.3.90-2
--------------
* Fri Jul 08 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-2
- update from CVS
  - ia64 stack protector support
  - handle DNS referral results as server errors (#162625)
  - ctan{,h}{,f,l} fixes (#160759)
  - pass argc, argv and envp also to executable's *ni_array
    functions (BZ#974)
  - add ellipsis to clone prototype (#161593)
  - fix glibc-profile (#162601)
  - nss_compat fixes
- use sysdeps/generic version of <bits/stdio-lock.h> in installed
  headers instead of NPTL version (#162634)

* Mon Jun 27 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-1
- update from CVS
  - stack protector support
  - fix xdr_{,u_}{longlong_t,hyper} on 64-bit arches (#161583)
- enable @GLIBC_2.4 symbols
- remove linuxthreads

gnome-applets-1:2.11.1-1
------------------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> 1:2.11.1-1
- Update to 2.11.1

gnome-bluetooth-0.5.1-13
------------------------
* Thu Jul 07 2005 Matthias Saou <http://freshrpms.net/> 0.5.1-13
- Minor spec file cleanups.
- Fix relative path for the icons in desktop files which no longer works
  with the icon cache.
- Remove useless zero epochs.
- Remove explicit python abi requirement, it's automatic for FC4 and up.

gnome-desktop-2.11.4-1
----------------------
* Sat Jul 09 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.4-1
- Update to 2.11.4

gnome-icon-theme-2.10.1-6
-------------------------
* Fri Jul 08 2005 John (J5) Palmieri <johnp at redhat.com> - 2.10.1-6
- update the redone icons with new ones from dfong

gnome-menus-2.11.1.1-1
----------------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> 2.11.1.1-1
- Update to 2.11.1.1
- Split off subpackages for python bindings and editor

gnome-panel-2.11.4-1
--------------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> 2.11.4-1
- Update to 2.11.4

gnome-utils-1:2.11.1-1
----------------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> 1:2.11.1-1
- Update to gnome-utils 2.11.1, gcalctool 5.6.14, zenity 2.11.0

gtk2-2.7.2-1
------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com>
- Update to 2.7.2

hwdata-0.160-1
--------------
* Thu Jul 07 2005 Bill Nottingham <notting at redhat.com> - 0.160-1
- move blacklist to /etc/modprobe.d, require new module-init-tools
- add LG monitors (#162466, #161734)
- add orinoco card (#161696)
- more mptfusion stuff (#107088)

* Thu Jun 23 2005 Bill Nottingham <notting at redhat.com>
- add Samsung monitor (#161013)

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_36rh
------------------------------------------
* Fri Jul 08 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_36rh
- Replace the binary ecj with a script to try and work around #162748.

* Fri Jul 08 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_35rh
- Don't optimise bootstrap-ecj at all to try and work around #162748.

* Fri Jul 08 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_34rh
- Optimise bootstrap-ecj less to try and work around #162748.

kernel-2.6.12-1.1425_FC5
------------------------
* Fri Jul 08 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc2-git2

* Thu Jul 07 2005 Dave Jones <davej at redhat.com>
- Fix exec-shield to not randomize to between end-of-binary and start-of-brk

mc-1:4.6.1a-0.11
----------------
* Fri Jul 08 2005 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.11
- update to mc-4.6.1-pre5
- sync .utf8, .userhost patch
- drop upstreamed .fixes patch

module-init-tools-3.2-0.pre7.1
------------------------------
* Fri Jul 08 2005 Bill Nottingham <notting at redhat.com> 3.2-0.pre7.1
- update to 3.2-pre7
- put modprobe.conf.dist in /etc/modprobe.d

openoffice.org-1:1.9.115-2.2.0.fc5
----------------------------------
* Thu Jul 07 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.115-2
- add openoffice.org-1.9.115.oooXXXXX.audio.withoutnas.patch
  and disable worthless nas/portaudio/sndfile stuff
- add openoffice.org-1.9.115.oooXXXXX.xsltproc.evenwithjava.patch
  and see if we can build faster with xsltproc

parted-1.6.23-1
---------------
* Fri Jul 08 2005 Chris Lumens <clumens at redhat.com> 1.6.23-1
- Updated to 1.6.23.
- Get rid of separate Mac patches that are now included in upstream.
- Update DASD and AIX patches.

pkgconfig-1:0.18.1-2
--------------------
* Fri Jul 08 2005 Matthias Clasen <mclasen at redhat.com> 1:0.18.1-2
- Fix the default search path

* Thu Jul 07 2005 Matthias Clasen <mclasen at redhat.com> 1:0.18.1-1
- Update to 0.18.1

selinux-policy-targeted-1.25.1-8
--------------------------------
* Fri Jul 08 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-8
- Fix saslauthd policy to allow imapd and shadow.

setools-2.1.1-1
---------------
* Wed May 25 2005 Dan Walsh <dwalsh at redhat.com> 2.1.1-0
- Upgrade to upstream version

udev-058-2
----------
* Thu Jul 07 2005 Harald Hoyer <harald at redhat.com> - 058-2
- compile with pie

xmlsec1-1.2.8-2
---------------
* Fri Jul 08 2005 Daniel Veillard <veillard at redhat.com> 1.2.8-2
- Enabling the mozilla-nss crypto backend

xorg-x11-6.8.2-42
-----------------
* Fri Jul 08 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-42
- Added xorg-x11-6.8.2-redhat-nv-disable-s2scopy-on-geforce-6x00.patch to
  work around "nv" driver bug, by disabling ScreenToScreenCopy on certain
  GeForce 6200/6800/6800 cards which the problem has been reported on,
  until there is a real upstream fix, as the current CVS head driver we
  now have, still suffers from the problem.  We may also need to blacklist
  other cards as new reports come in.  (#157715)

yum-2.3.4-1
-----------
* Fri Jul 08 2005 Jeremy Katz <katzj at redhat.com> - 2.3.4-1
- update to 2.3.4
- use %{python_sitelib} in the file list

Broken deps for s390x
----------------------------------------------------------
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	dhcp - 10:3.0.2-14.FC5.s390x requires kernel >= 0:2.2.18
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390x requires gjdoc
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	eel2 - 2.10.0-2.s390x requires libgnome-menu.so.0()(64bit)
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	bug-buddy - 1:2.10.0-1.s390x requires libgnome-menu.so.0()(64bit)
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4



Broken deps for ia64
----------------------------------------------------------
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	bug-buddy - 1:2.10.0-1.ia64 requires libgnome-menu.so.0()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	eel2 - 2.10.0-2.ia64 requires libgnome-menu.so.0()(64bit)
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	rgmanager - 1.9.31-3.ia64 requires ccs
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ia64 requires gjdoc



Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	eel2 - 2.10.0-2.i386 requires libgnome-menu.so.0
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	bug-buddy - 1:2.10.0-1.i386 requires libgnome-menu.so.0
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	eel2 - 2.10.0-2.ppc requires libgnome-menu.so.0
	bug-buddy - 1:2.10.0-1.ppc requires libgnome-menu.so.0
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	bug-buddy - 1:2.10.0-1.x86_64 requires libgnome-menu.so.0()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	eel2 - 2.10.0-2.x86_64 requires libgnome-menu.so.0()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	eel2 - 2.10.0-2.ppc64 requires libgnome-menu.so.0()(64bit)
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ppc64 requires gjdoc
	firstboot - 1.3.43-1.noarch requires system-config-display
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	bug-buddy - 1:2.10.0-1.ppc64 requires libgnome-menu.so.0()(64bit)
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)



Broken deps for s390
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390 requires gjdoc
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	dhcp - 10:3.0.2-14.FC5.s390 requires kernel >= 0:2.2.18
	bug-buddy - 1:2.10.0-1.s390 requires libgnome-menu.so.0
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	eel2 - 2.10.0-2.s390 requires libgnome-menu.so.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp





From dwmw2 at infradead.org  Sat Jul  9 12:27:09 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 09 Jul 2005 13:27:09 +0100
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <42CEDC1F.2030508@redhat.com>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<42CEDC1F.2030508@redhat.com>
Message-ID: <1120912029.23706.34.camel@baythorne.infradead.org>

On Fri, 2005-07-08 at 13:03 -0700, Ulrich Drepper wrote:
> Ralf Ertzinger wrote:
> > So glibc will have to be excluded from the update frenzy :)
> 
> As I said, in a couple of days we'll hopefully have the gcc, binutils,
> glibc pieces in place to make the next big change in the build
> procedures and then you cannot do *any* update unless you get the new
> glibc.  The rpm infrastructure should catch those requirements but be
> warned.  We'll announce the build changes ahead of time as well.

Can we drop -fsigned-char on PPC at the same time?

Currently, it's massively inconsistent because some packages use
$RPM_OPT_FLAGS while others don't. If you build an executable from a C
file with just 'make testprog', you'll end up with different signedness
of 'char' from that which glibc was built with, etc.

-- 
dwmw2




From divij at innomedia.soft.net  Sat Jul  9 13:03:26 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Sat, 09 Jul 2005 18:33:26 +0530
Subject: nptl configuration
Message-ID: <1120914205.6833.2.camel@localhost.localdomain>

Hi,
    I want to know that how can i configure nptl on my linux 2.6.10 kernel.I am confused little bit because when  I give 
the command:->getconf GNU_LIBPTHREAD_VERSION it is returning the value nptl-0.61 but when i am giving the command:->
/lib/libc.so.6 where it is giving following output:->linuxthreads-0.10 by Xavier Leroy instead of 
Native POSIX Threads Library by Ulrich Drepper et al I am using the gcc version 3.3.3 and Thread Model:-POSIX But when I 
am giving:->/lib/tls/libc.so.6 it is giving:->Native POSIX Threads Library by Ulrich Drepper et al So tell me whether it 
is working or not.

Thanks 
Divij Kumar Bhatt






From divij at innomedia.soft.net  Sat Jul  9 13:08:56 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Sat, 09 Jul 2005 18:38:56 +0530
Subject: nptl configuration
Message-ID: <1120914536.7035.0.camel@localhost.localdomain>

Hi,
    I want to know that how can i configure nptl on my linux 2.6.10
kernel.I am confused little bit because when  I give 
the command:->getconf GNU_LIBPTHREAD_VERSION it is returning the value
nptl-0.61 but when i am giving the command:->
/lib/libc.so.6 where it is giving following output:->linuxthreads-0.10
by Xavier Leroy instead of 
Native POSIX Threads Library by Ulrich Drepper et al I am using the gcc
version 3.3.3 and Thread Model:-POSIX But when I 
am giving:->/lib/tls/libc.so.6 it is giving:->Native POSIX Threads
Library by Ulrich Drepper et al So tell me whether it 
is working or not.

Thanks 
Divij Kumar Bhatt



From mike at plan99.net  Sat Jul  9 13:33:33 2005
From: mike at plan99.net (Mike Hearn)
Date: Sat, 09 Jul 2005 14:33:33 +0100
Subject: new in 2005-7-9 glibc: no more LinuxThreads
References: <42CEB158.9080308@redhat.com>
Message-ID: <pan.2005.07.09.13.33.32.896292@plan99.net>

On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
> In the last year we've hardly heard about
> any problem related to LT vs NPTL and the F4 switch to default to linking
> with NPTL also didn't cause any problems we know of.

That's because people got the message that you guys didn't care, not
because the programs that needed LinuxThreads magically disappeared.

Off the top of my head I can think of 3 commercial games which need it
(games are virtually never updated more than 6 months after release), and
I have a copy of Domino lying around which needs LT too. I'm sure there
are plenty of others, the change to NPTL really did break a lot of
software.

Most of the old Loki games no longer work, for various reasons, NPTL
amongst them.

I'm not expecting sympathy from you. These days I don't play many
games anyway. However, don't assume that silence on the matter means there
are no problems. It means people got tired of being told that the programs
they use don't matter.

thanks -mike



From pri.rhl4 at iadonisi.to  Sat Jul  9 14:06:26 2005
From: pri.rhl4 at iadonisi.to (Paul Iadonisi)
Date: Sat, 09 Jul 2005 10:06:26 -0400
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <pan.2005.07.09.13.33.32.896292@plan99.net>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
Message-ID: <1120917986.25096.13.camel@md.nc.linuxlobbyist.org>

On Sat, 2005-07-09 at 14:33 +0100, Mike Hearn wrote:
> On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
> > In the last year we've hardly heard about
> > any problem related to LT vs NPTL and the F4 switch to default to linking
> > with NPTL also didn't cause any problems we know of.
> 
> That's because people got the message that you guys didn't care, not
> because the programs that needed LinuxThreads magically disappeared.

  Of course, 'you guys' should be translated 'Linux kernel and glibc
developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in his
original post...LT is discontinued *upstream*.
  Aside from all other technical issues, it thoroughly amazes me that
Red Hat still gets most of the flack for the move NPTL when it is an
UPSTREAM movement.  Red Hat just happened to be the first (or only?) one
(that I know of) to back-port it to the 2.4 kernel.  Whether or not Red
Hat developed it originally or not shouldn't matter...it's been accepted
upstream.

> I'm not expecting sympathy from you. These days I don't play many
> games anyway. However, don't assume that silence on the matter means there
> are no problems. It means people got tired of being told that the programs
> they use don't matter.

  Well, I guess those silent folks (both of them) will just have to
stick to Red Hat's Mothers' Day release.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets



From arjanv at redhat.com  Sat Jul  9 14:40:19 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 09 Jul 2005 16:40:19 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120917986.25096.13.camel@md.nc.linuxlobbyist.org>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
	<1120917986.25096.13.camel@md.nc.linuxlobbyist.org>
Message-ID: <1120920019.3176.35.camel@laptopd505.fenrus.org>

On Sat, 2005-07-09 at 10:06 -0400, Paul Iadonisi wrote:
> On Sat, 2005-07-09 at 14:33 +0100, Mike Hearn wrote:
> > On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
> > > In the last year we've hardly heard about
> > > any problem related to LT vs NPTL and the F4 switch to default to linking
> > > with NPTL also didn't cause any problems we know of.
> > 
> > That's because people got the message that you guys didn't care, not
> > because the programs that needed LinuxThreads magically disappeared.
> 
>   Of course, 'you guys' should be translated 'Linux kernel and glibc
> developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in his
> original post...LT is discontinued *upstream*.

and there is a reason for that. LT was unfixably buggy. (well not
entirely unfixable, the fix is called NPTL), and was holding back
improvements to glibc bigtime. In addition, NPTL *is* compatible to
linuxthreads, but not bug-to-bug compatible, it can't be after all,
since the goal of NPTL was to fix some of the longstanding bugs in LT.

Now there are some apps that depend on some of the bugs in LT. That's a
tricky problem, since what would have happened if we would have found a
way to fix those bugs inside LT instead of in a separate lib??



Also note that some of the "problems" people blame on NPTL interaction
are not that per se, but are new kernel features that just happen to get
disabled with old LT. Again those kernel features (of which I'm
responsible for some of them) change behavior within the allowed bounds
(eg they don't do anything that couldn't happen anyway) but a few
applications have really bad and broken assumptions but just got lucky
most of the time. It sucks to have to depend on such applications, I
realize that. At the same time there is a problem if we'd avoid all
changes that would break ANY defective assumption out there, since
progress would not be possible at all. Do not underestimate how far that
would go (there are some REALLY broken assumptions out there) since any
bug you fix anywhere could potentially be depended on by some app out
there somewhere.

It's not that we don't sympathize with people who have those few apps
out there that don't work in "new linux". It's that the choice between
breaking a few apps and a more secure[1], more standards compliant and
less buggy linux is a hard one but made for the later. It's a balance,
and there have been three years for transition, and the point where it
no longer is possible to keep doing both has come [2]... I mean, even
Red Hat Linux 9 already defaulted to NPTL....
 
There is also another angle to this. Old Old linuxthreads (with fixed
size 2Mb stacks) was kept around for compatibility with old broken apps
that internally used knowledge that the stack used to be 2Mb in size.
Because it was kept around, vendors decided to not fix their apps, not
even in newer compiles/releases. As a result 7 years later there were
still broken apps being shipped.... Fedora Core is not a maintenance
release of enterprise software, it's a linux distribution designed to
bring new technology and features to the masses. Hopefully those masses
include ISVs who will now get of their butts to fix their apps
quicker ;)

Greetings,
    Arjan van de Ven


[1] Half of the problems out there are probably caused by things done in
the ExecShield project to increase linux security and not NPTL per se,
see the upcomming issue of Red Hat Magazine for more details on what
security features have been added in the least few years and what value
they bring to linux. 

[2] The upcomming -fstack-protector feature in gcc/glibc is the nail in
the coffin for LT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050709/1ff97233/attachment.sig>

From fedora at camperquake.de  Sat Jul  9 15:31:38 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 9 Jul 2005 17:31:38 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120917986.25096.13.camel@md.nc.linuxlobbyist.org>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
	<1120917986.25096.13.camel@md.nc.linuxlobbyist.org>
Message-ID: <20050709173138.69073aee@nausicaa.camperquake.de>

Hi.

Paul Iadonisi <pri.rhl4 at iadonisi.to> wrote:

>   Of course, 'you guys' should be translated 'Linux kernel and glibc
> developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in his
> original post...LT is discontinued *upstream*.

Well, Ulrich _is_ upstream wrt glibc, so....

Note: this is not an accusation, just a stating of fact.
I think it has been time for LT to die for quite some time.

-- 
In case anyone still has any illusions about slackware, it now loads
fvwm95 as the default window manager. As someone else said recently, Oi!
Volkerding! LART!!!  -- Pete Ehlke



From i.pilcher at comcast.net  Sat Jul  9 17:02:42 2005
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Sat, 09 Jul 2005 12:02:42 -0500
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120920019.3176.35.camel@laptopd505.fenrus.org>
References: <42CEB158.9080308@redhat.com>	<pan.2005.07.09.13.33.32.896292@plan99.net>	<1120917986.25096.13.camel@md.nc.linuxlobbyist.org>
	<1120920019.3176.35.camel@laptopd505.fenrus.org>
Message-ID: <daovvk$kgm$1@sea.gmane.org>

Arjan van de Ven wrote:
> still broken apps being shipped.... Fedora Core is not a maintenance
> release of enterprise software, it's a linux distribution designed to
> bring new technology and features to the masses. Hopefully those masses
> include ISVs who will now get of their butts to fix their apps
> quicker ;)

I think you've hit on a problem.  The ISVs that I work with are
completely focused on "Enterprise Linux" distributions -- which is the
idea.  AFAICT, they have not gotten the message that they should be
testing their software on Fedora Core.

Perhaps each release of Fedora Core should be wrapped up in a nice box
and shipped out to all of the ISVs as a RHEL "Technical Preview" or
some such thing.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From arjanv at redhat.com  Sat Jul  9 17:18:31 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 09 Jul 2005 19:18:31 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <daovvk$kgm$1@sea.gmane.org>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
	<1120917986.25096.13.camel@md.nc.linuxlobbyist.org>
	<1120920019.3176.35.camel@laptopd505.fenrus.org>
	<daovvk$kgm$1@sea.gmane.org>
Message-ID: <1120929512.3176.44.camel@laptopd505.fenrus.org>

On Sat, 2005-07-09 at 12:02 -0500, Ian Pilcher wrote:
> Arjan van de Ven wrote:
> > still broken apps being shipped.... Fedora Core is not a maintenance
> > release of enterprise software, it's a linux distribution designed to
> > bring new technology and features to the masses. Hopefully those masses
> > include ISVs who will now get of their butts to fix their apps
> > quicker ;)
> 
> I think you've hit on a problem.  The ISVs that I work with are
> completely focused on "Enterprise Linux" distributions -- which is the
> idea.  AFAICT, they have not gotten the message that they should be
> testing their software on Fedora Core.

to be fair both RHEL3 and RHEL4 default to NPTL....


> Perhaps each release of Fedora Core should be wrapped up in a nice box
> and shipped out to all of the ISVs as a RHEL "Technical Preview" or
> some such thing.

there's ongoing work in RH to work with ISVs better (well isn't there
always :). It's sometimes hard, for some of these ISVs linux is a really
really small portion of their customer base and they spend as little
money/time on it as possible. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050709/0940adfa/attachment.sig>

From nmiell at comcast.net  Sat Jul  9 19:44:43 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 09 Jul 2005 12:44:43 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120912029.23706.34.camel@baythorne.infradead.org>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<42CEDC1F.2030508@redhat.com>
	<1120912029.23706.34.camel@baythorne.infradead.org>
Message-ID: <1120938283.2944.1.camel@localhost.localdomain>

On Sat, 2005-07-09 at 13:27 +0100, David Woodhouse wrote:
> On Fri, 2005-07-08 at 13:03 -0700, Ulrich Drepper wrote:
> > Ralf Ertzinger wrote:
> > > So glibc will have to be excluded from the update frenzy :)
> > 
> > As I said, in a couple of days we'll hopefully have the gcc, binutils,
> > glibc pieces in place to make the next big change in the build
> > procedures and then you cannot do *any* update unless you get the new
> > glibc.  The rpm infrastructure should catch those requirements but be
> > warned.  We'll announce the build changes ahead of time as well.
> 
> Can we drop -fsigned-char on PPC at the same time?
> 
> Currently, it's massively inconsistent because some packages use
> $RPM_OPT_FLAGS while others don't. If you build an executable from a C
> file with just 'make testprog', you'll end up with different signedness
> of 'char' from that which glibc was built with, etc.
> 

My understanding was that glibc doesn't care which signedness char has.
(Although, other libraries may matter. Perhaps a section on not using
char in library ABIs is in order for dsohowto.pdf)

-- 
Nicholas Miell <nmiell at comcast.net>



From nmiell at comcast.net  Sat Jul  9 20:50:56 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 09 Jul 2005 13:50:56 -0700
Subject: A quick look at the yum mirrorlists
Message-ID: <1120942256.2944.26.camel@localhost.localdomain>

After getting sick of yum trying to parse 404 Not Found error HTML as
repomd.xml (btw, Seth: yum will try to parse 404 Not Found error HTML as
repomd.xml), I used a quick mirror validation script of my own creation
(see below) on the official FC 4 mirror lists and determined that a lot
of the mirrors in that list really shouldn't be there.

http://dl.atrpms.net/mirrors/fedoracore/4/ppc/os/
	HTTP/1.1 404 Not Found
http://dl.atrpms.net/mirrors/fedoracore/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://dl.atrpms.net/mirrors/fedoracore/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://fedora.arcticnetwork.ca/4/ppc/os/
	HTTP/1.1 404 Not Found
http://fedora.arcticnetwork.ca/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://fedora.arcticnetwork.ca/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://fedora.ngi.it/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://fedora.ngi.it/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://fedora.ngi.it/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://fr.rpmfind.net/linux/fedora/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://fr.rpmfind.net/linux/fedora/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://fr.rpmfind.net/linux/fedora/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/4/i386/os/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/4/x86_64/os/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/updates/4/i386/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.ale.org/pub/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/4/i386/os/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/4/x86_64/os/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/updates/4/i386/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.chg.ru/pub/Linux/fedora/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/4/i386/os/
	HTTP/1.1 403 Forbidden
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/4/x86_64/os/
	HTTP/1.1 404 Not Found
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/4/i386/os/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/4/ppc/os/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/4/x86_64/os/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/4/i386/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/4/ppc/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/4/x86_64/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/testing/4/i386/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/testing/4/ppc/
	IPv6 only
http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/testing/4/x86_64/
	IPv6 only
http://ftp.lug.ro/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://ftp.lug.ro/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.lug.ro/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.tecnoera.com/pub/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://ftp.tecnoera.com/pub/fedora/linux/core/4/x86_64/os/
	HTTP/1.1 404 Not Found
http://ftp.tecnoera.com/pub/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://ftp.tecnoera.com/pub/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.tecnoera.com/pub/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://ftp.udl.es/pub/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://ftp.udl.es/pub/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.udl.es/pub/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://ftp.upjs.sk/pub/linux/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://klid.dk/homeftp/fedora/linux/core/4/i386/os/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/4/ppc/os/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/4/x86_64/os/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/updates/4/i386/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/updates/4/x86_64/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 403 Forbidden
http://klid.dk/homeftp/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 403 Forbidden
http://less.cogeco.net/pub/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://less.cogeco.net/pub/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://less.cogeco.net/pub/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://less.cogeco.net/pub/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://less.cogeco.net/pub/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/4/i386/os/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/4/ppc/os/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/4/x86_64/os/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/4/i386/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/4/x86_64/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 403 Forbidden
http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 403 Forbidden
http://mirror2etf.bg.ac.yu/distributions/fedora/4/i386/os/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/4/ppc/os/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/4/x86_64/os/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/updates/4/i386/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/updates/4/ppc/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/updates/4/x86_64/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/updates/testing/4/i386/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/updates/testing/4/ppc/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror2etf.bg.ac.yu/distributions/fedora/updates/testing/4/x86_64/
	Host mirror2etf.bg.ac.yu not found: 3(NXDOMAIN)
http://mirror.averse.net/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://mirror.averse.net/fedora/linux/core/4/x86_64/os/
	HTTP/1.1 404 Not Found
http://mirror.averse.net/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://mirror.averse.net/fedora/linux/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found
http://mirror.averse.net/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://mirror.averse.net/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://mirror.averse.net/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/updates/4/i386/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://mirror.netglobalis.net/pub/fedora/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found
http://mirrors.bevc.net/fedora/4/i386/os/
	HTTP/1.1 404 Not Found
http://mirrors.bevc.net/fedora/4/ppc/os/
	HTTP/1.1 404 Not Found
http://mirrors.bevc.net/fedora/4/x86_64/os/
	HTTP/1.1 404 Not Found
http://mirrors.bevc.net/fedora/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://mirrors.playboy.com/fedora/4/ppc/os/
	HTTP/1.1 404 Not Found
http://mirrors.playboy.com/fedora/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://mirrors.playboy.com/fedora/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://mirror.usu.edu/mirrors/fedora/linux/core/updates/4/i386/
	HTTP/1.1 404 Not Found
http://mirror.usu.edu/mirrors/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://mirror.usu.edu/mirrors/fedora/linux/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found
http://srl.cs.jhu.edu/YUM/fedora-core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://srl.cs.jhu.edu/YUM/fedora-core/updates/4/ppc/
	HTTP/1.1 404 Not Found
http://srl.cs.jhu.edu/YUM/fedora-core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://www.fedora.is/fedora/core/4/ppc/os/
	HTTP/1.1 404 Not Found
http://zeniv.linux.org.uk/pub/distributions/fedora/linux/core/updates/testing/4/i386/
	HTTP/1.1 404 Not Found
http://zeniv.linux.org.uk/pub/distributions/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found
http://zeniv.linux.org.uk/pub/distributions/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found


My verification script:

(for m in $(cat mirrorlist.txt); do
echo "$m $(curl -I -s ${m}repodata/repomd.xml | head -n 1)";
done) > mirrorstatus.txt
egrep -v "200 OK|302 Found" mirrorstatus.txt > badmirrors.txt

and then follow up with some manual result filtering.

-- 
Nicholas Miell <nmiell at comcast.net>



From skvidal at phy.duke.edu  Sat Jul  9 21:17:07 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 09 Jul 2005 17:17:07 -0400
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120942256.2944.26.camel@localhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
Message-ID: <1120943827.22153.15.camel@cutter>

On Sat, 2005-07-09 at 13:50 -0700, Nicholas Miell wrote:
> After getting sick of yum trying to parse 404 Not Found error HTML as
> repomd.xml (btw, Seth: yum will try to parse 404 Not Found error HTML as
> repomd.xml),

1. that's only true if the website returns a 200 to the 404 page -
instead of a 404 like it should.

2. working around those broken websites has been fixed in yum 2.3.4

-sv




From tibbs at math.uh.edu  Sat Jul  9 21:57:44 2005
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Sat, 09 Jul 2005 16:57:44 -0500
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <ufau0j55avc.fsf@epithumia.math.uh.edu> (Jason L. Tibbitts,
	III's message of "Fri, 08 Jul 2005 14:57:43 -0500")
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<ufau0j55avc.fsf@epithumia.math.uh.edu>
Message-ID: <ufa7jfz4p7r.fsf@epithumia.math.uh.edu>

Hey, I'm glad that someone was kind enough to point me towards Octave,
which I was actually familiar with since, frankly, I'm not a complete
idiot and would rather not drain my budget paying Matlab licensing
fees unless I had no choice.

However, I would still really like to know if there's a relatively
simple way to determine whether or not a particular piece of software
makes use of LinuxThreads and will thus break on the new
non-LT-capable glibc releases.

Thanks,
-- 
  Jason L Tibbitts III - tibbs at math.uh.edu - 713/743-3486 - 660PGH - 94 PC800
       System Manager:  University of Houston Department of Mathematics 



From roland at redhat.com  Sat Jul  9 22:51:45 2005
From: roland at redhat.com (Roland McGrath)
Date: Sat,  9 Jul 2005 15:51:45 -0700 (PDT)
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: Jason L Tibbitts III's message of  Saturday,
	9 July 2005 16:57:44 -0500 <ufa7jfz4p7r.fsf@epithumia.math.uh.edu>
Message-ID: <20050709225145.9EF2B1809FC@magilla.sf.frob.com>

> However, I would still really like to know if there's a relatively
> simple way to determine whether or not a particular piece of software
> makes use of LinuxThreads and will thus break on the new
> non-LT-capable glibc releases.

No executable will use linuxthreads without being run with special
environment variables.  If there are many binaries and scripts and it's
hard to tell what might be going on, you can take a running application
and look at its /proc/PID/maps to see which libraries are being mapped.
On FC4 the linuxthreads libraries are in /lib/obsolete/linuxthreads/,
so that's pretty easy to spot.

On earlier versions it's in different places.  But if you are concerned
about FC5 compatibility, the first thing to do anyway is make sure you are
happy with upgrading to FC4.



From veillard at redhat.com  Sat Jul  9 23:20:17 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Sat, 9 Jul 2005 19:20:17 -0400
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120942256.2944.26.camel@localhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
Message-ID: <20050709232016.GG31114@redhat.com>

On Sat, Jul 09, 2005 at 01:50:56PM -0700, Nicholas Miell wrote:
> After getting sick of yum trying to parse 404 Not Found error HTML as
> repomd.xml (btw, Seth: yum will try to parse 404 Not Found error HTML as
> repomd.xml), I used a quick mirror validation script of my own creation
> (see below) on the official FC 4 mirror lists and determined that a lot
> of the mirrors in that list really shouldn't be there.
> 
> http://fr.rpmfind.net/linux/fedora/core/4/ppc/os/
> 	HTTP/1.1 404 Not Found
> http://fr.rpmfind.net/linux/fedora/core/updates/4/ppc/
> 	HTTP/1.1 404 Not Found
> http://fr.rpmfind.net/linux/fedora/core/updates/testing/4/ppc/
> 	HTTP/1.1 404 Not Found

  How many are using ppc ? I didn't had much space until a few hours ago
to add it, but I'm still pondering the effectiveness of the use of the
disk space. Apparently I'm not the only one, 

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From mpeters at mac.com  Sat Jul  9 23:53:18 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Sat, 09 Jul 2005 16:53:18 -0700
Subject: A quick look at the yum mirrorlists
In-Reply-To: <20050709232016.GG31114@redhat.com>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
Message-ID: <1120953198.2759.6.camel@locolhost.localdomain>

On Sat, 2005-07-09 at 19:20 -0400, Daniel Veillard wrote:

> 
>   How many are using ppc ? I didn't had much space until a few hours ago
> to add it, but I'm still pondering the effectiveness of the use of the
> disk space. Apparently I'm not the only one, 

I use Fedora on PPC - but I'm the only one (outside of fedora user
lists) that I personally know of.

Most ppc people I know use YellowDog or gentoo.
I suppose things like xterm not currently working in ppc doesn't help
the Fedora cause on that platform, which will be shrinking now that
Apple has committed to Intel.

Still though - if a mirror doesn't have ppc, it shouldn't be part of a
mirror list used by the ppc platform.



From cmadams at hiwaay.net  Sat Jul  9 23:56:11 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 9 Jul 2005 18:56:11 -0500
Subject: Problems with Bugzilla
Message-ID: <20050709235611.GA831735@hiwaay.net>

I don't know if anyone is available to look at it on the weekends, but
bugzilla.redhat.com is apparantly out of disk on at least one FS.  I get
an Internal Server Error trying to do queries, and when I tried to send
a message to bugzilla at redhat.com, I got "bugzilla at bugzilla.redhat.com...
Deferred: 452 4.4.5 Insufficient disk space; try again later".

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From nmiell at comcast.net  Sun Jul 10 00:21:56 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 09 Jul 2005 17:21:56 -0700
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120953198.2759.6.camel@locolhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
Message-ID: <1120954916.2944.31.camel@localhost.localdomain>

On Sat, 2005-07-09 at 16:53 -0700, Michael A. Peters wrote:
> On Sat, 2005-07-09 at 19:20 -0400, Daniel Veillard wrote:
> 
> > 
> >   How many are using ppc ? I didn't had much space until a few hours ago
> > to add it, but I'm still pondering the effectiveness of the use of the
> > disk space. Apparently I'm not the only one, 
> 
> I use Fedora on PPC - but I'm the only one (outside of fedora user
> lists) that I personally know of.
> 
> Most ppc people I know use YellowDog or gentoo.
> I suppose things like xterm not currently working in ppc doesn't help
> the Fedora cause on that platform, which will be shrinking now that
> Apple has committed to Intel.
> 
> Still though - if a mirror doesn't have ppc, it shouldn't be part of a
> mirror list used by the ppc platform.

That would require per-platform mirror lists, which isn't currently
done.

Not too difficult to do, though. Create a new version of fedora-release
with the modified mirrorlist URLs and then make the existing mirrorlist
URLs return a single repo containing only the new version of
fedora-release.

-- 
Nicholas Miell <nmiell at comcast.net>



From nmiell at comcast.net  Sun Jul 10 00:24:27 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 09 Jul 2005 17:24:27 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <20050709225145.9EF2B1809FC@magilla.sf.frob.com>
References: <20050709225145.9EF2B1809FC@magilla.sf.frob.com>
Message-ID: <1120955067.2944.34.camel@localhost.localdomain>

On Sat, 2005-07-09 at 15:51 -0700, Roland McGrath wrote:
> > However, I would still really like to know if there's a relatively
> > simple way to determine whether or not a particular piece of software
> > makes use of LinuxThreads and will thus break on the new
> > non-LT-capable glibc releases.
> 
> No executable will use linuxthreads without being run with special
> environment variables.  If there are many binaries and scripts and it's
> hard to tell what might be going on, you can take a running application
> and look at its /proc/PID/maps to see which libraries are being mapped.
> On FC4 the linuxthreads libraries are in /lib/obsolete/linuxthreads/,
> so that's pretty easy to spot.
> 
> On earlier versions it's in different places.  But if you are concerned
> about FC5 compatibility, the first thing to do anyway is make sure you are
> happy with upgrading to FC4.

I don't think that he's asking if there's a way to figure out what uses
LinuxThreads, he's asking if there's a way to figure out what breaks
with NPTL.

And the answer to that question is: no, there isn't any way, besides
noticing that something dies/behaves erratically/etc. with NPTL but not
with LinuxThreads.

-- 
Nicholas Miell <nmiell at comcast.net>



From wtogami at redhat.com  Sun Jul 10 00:42:41 2005
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 09 Jul 2005 14:42:41 -1000
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <pan.2005.07.09.13.33.32.896292@plan99.net>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
Message-ID: <42D06F01.9000704@redhat.com>

Mike Hearn wrote:
> Off the top of my head I can think of 3 commercial games which need it
> (games are virtually never updated more than 6 months after release), and
> I have a copy of Domino lying around which needs LT too. I'm sure there
> are plenty of others, the change to NPTL really did break a lot of
> software.
> 
> Most of the old Loki games no longer work, for various reasons, NPTL
> amongst them.

Here is a question.  Will a FC3 chroot running on a FC5+ kernel allow 
apps running inside the chroot to use linuxthreads?  If so then this 
might be a way of running old buggy games?

Warren Togami
wtogami at redhat.com



From dfarning at sbcglobal.net  Sun Jul 10 01:36:04 2005
From: dfarning at sbcglobal.net (david)
Date: Sat, 09 Jul 2005 20:36:04 -0500
Subject: A quick look at the yum mirrorlists-subscribe feature
In-Reply-To: <1120954916.2944.31.camel@localhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>	<20050709232016.GG31114@redhat.com>	<1120953198.2759.6.camel@locolhost.localdomain>
	<1120954916.2944.31.camel@localhost.localdomain>
Message-ID: <42D07B84.4010109@sbcglobal.net>

Nicholas Miell wrote:

>Not too difficult to do, though. Create a new version of fedora-release
>with the modified mirrorlist URLs and then make the existing mirrorlist
>URLs return a single repo containing only the new version of
>fedora-release.
>
>  
>
I currently working on such a system.  I am using the concept of 
subscribe/un-subscribe to indicate if a mirror is carrying a copy a 
particular repoTuple(product,release,arch).  It is working well at 
generating test mirrorlists by repoTuple(product,release,arch) and 
region/continent.  I'm not sure how too bootstrap in the data.  300 
mirror X  5 releases(more when you start to consider updates and testing 
releases) X several arch is a lot of possibilities.  I may just brute 
force it by checking every mirror against every every repoTuple once a 
day for a couple of weeks.  Then if sentry (the probe system) has not 
successfully hit a repoTuple, it will automatically mark the repoTuple 
as un-subscribed and require manually intervention to resubscribe it.
-dtf



From roland at redhat.com  Sun Jul 10 02:09:00 2005
From: roland at redhat.com (Roland McGrath)
Date: Sat,  9 Jul 2005 19:09:00 -0700 (PDT)
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: Warren Togami's message of  Saturday,
	9 July 2005 14:42:41 -1000 <42D06F01.9000704@redhat.com>
Message-ID: <20050710020900.6A15B1809FD@magilla.sf.frob.com>

> Here is a question.  Will a FC3 chroot running on a FC5+ kernel allow 
> apps running inside the chroot to use linuxthreads?  If so then this 
> might be a way of running old buggy games?

Yes.



From nmiell at comcast.net  Sun Jul 10 02:20:38 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 09 Jul 2005 19:20:38 -0700
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120942256.2944.26.camel@localhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
Message-ID: <1120962038.17002.5.camel@localhost.localdomain>

On Sat, 2005-07-09 at 13:50 -0700, Nicholas Miell wrote:
> After getting sick of yum trying to parse 404 Not Found error HTML as
> repomd.xml (btw, Seth: yum will try to parse 404 Not Found error HTML as
> repomd.xml), I used a quick mirror validation script of my own creation
> (see below) on the official FC 4 mirror lists and determined that a lot
> of the mirrors in that list really shouldn't be there.
> 

Missed a few, mostly because they're 404 but returning 302 (now I see
what Seth was complaining about).

http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/4/ppc/os/
	HTTP/1.1 404 Not Found (but replies with HTTP/1.1 302 Found)
http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/4/x86_64/os/
	HTTP/1.1 404 Not Found (but replies with HTTP/1.1 302 Found)
http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/4/ppc/
	HTTP/1.1 404 Not Found (but replies with HTTP/1.1 302 Found)
http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/4/x86_64/
	HTTP/1.1 404 Not Found (but replies with HTTP/1.1 302 Found)
http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/testing/4/ppc/
	HTTP/1.1 404 Not Found (but replies with HTTP/1.1 302 Found)
http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/testing/4/x86_64/
	HTTP/1.1 404 Not Found (but replies with HTTP/1.1 302 Found)

This makes me wonder if the IPv6 versions even work. I can't test that,
but it would be nice if somebody with IPv6 connectivity would take a
look.

-- 
Nicholas Miell <nmiell at comcast.net>



From hichetu at gmail.com  Sun Jul 10 10:58:49 2005
From: hichetu at gmail.com (Chetan Raj)
Date: Sun, 10 Jul 2005 16:28:49 +0530
Subject: FireFox Xml Rendering using Xsl is broken in Fedora Core 4
Message-ID: <27b710b105071003585cb29c02@mail.gmail.com>

Hi All,

I use CUnit for my unit-testing framework. (http://cunit.sourceforge.net/)

It generates an Xml file as an output and uses Xsl to render the same on the 
browser.

Now, after moving to Fedora Core 4 from RedHat 9.0, when I open the xml in 
firefox 1.04 ,I get the following error.

Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:
file:///home/chetan//TEST/BIN/CUnit-Run.xsl

The same was rendering fine in firefox 1.04 on Redhat 9.0.

I have checked /etc/mime.types and it does have an entry for xsl. I have 
also added xslt and dtd to the file as show,

text/xml xsl xml dtd xslt


Any clues why this doesn't work on Fedora Core 4? And what is the work 
around?

Thanks in advance for any help....

Chetan Raj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050710/28f42170/attachment.htm>

From buildsys at redhat.com  Sun Jul 10 11:13:52 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 10 Jul 2005 07:13:52 -0400
Subject: rawhide report: 20050710 changes
Message-ID: <200507101113.j6ABDq63006345@porkchop.devel.redhat.com>

 

 
Updated Packages:

bug-buddy-1:2.10.0-2
--------------------
* Sat Jul 09 2005 Matthias Clasen <mclasen at redhat.com> 2.10.0-2
- Rebuilt

eel2-2.11.3-1
-------------
* Sat Jul 09 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
- Update to 2.11.3

gcc-4.0.1-1
-----------
* Fri Jul 08 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.1-1
- update from CVS
  - GCC 4.0.1 release
  - PRs tree-optimization/22000, tree-optimization/22171, middle-end/21985,
	target/22260, c/21911, c/22308, target/22083, middle-end/17961
  - use SCHED_OTHER rather than SCHED_RR in libjava (Andrew Haley, #152386)
  - fix compound literal handling (Joseph S. Myers, #160018, c/22013, c/22098)
- -fstack-protector{,-all} support (Richard Henderson)
- fix -march=i386 -masm=intel -fpic (#162585)
- make sure libstdc++ mt allocator calls pthread_key_delete before
  libstdc++ dlclose (#161061, PR libstdc++/22309)
- accept fortran ENTRY without () even in FUNCTIONs (#161634)
- fix fortran handling of ENTRY return var names as rvalues (161669)
- fix fortran ICE on invalid preprocessor line (#161679)
- fix fortran handling of long preprocessor lines (#161680)
- add -std=legacy gfortran option (Roger Sayle)
- support logical to boolean (and vice versa) conversions as legacy
  fortran extension (Roger Sayle)
- fortran Hollerith constant and character array fixes (Feng Wang, #161430)
- add sparc and sparc64 to build_ada arches (#161865)

libtool-1.5.18-3
----------------
* Sat Jul 09 2005 Jakub Jelinek <jakub at redhat.com> 1.5.18-3
- rebuilt with GCC 4.0.1.

libwnck-2.10.0-4.fc4
--------------------
* Mon May 30 2005 Elijah Newren  <newren at gamil.com> 2.10.0-4
- add support for urgent hint (#157271)

openoffice.org-1:1.9.116-1.2.0.fc5
----------------------------------
* Sat Jul 09 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.116-1
- bump to new version, Hamburg burning the midnight oil apparently
- add openoffice.org-1.9.115.ooo51755.scp2.parallel.patch
- drop integrated openoffice.org-1.9.111.ooo51091.exportgcjsymbolname.jvmaccess.patch

* Fri Jul 08 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.115-3
- in rawhide we should be able to use system-xmlsec1 now with 
  system-xmlsec patch

syslinux-3.09-2
---------------
* Sat Jul 09 2005 Peter Jones <pjones at redhat.com> - 3.09-2
- Update to 3.09

* Thu Jun 16 2005 Peter Jones <pjones at redhat.com> - 3.08.92-1
- Update to 3.09-pre2, to fix the i915 .bss overflow bug

* Thu May 19 2005 Peter Jones <pjones at redhat.com> - 3.08-3
- Fix filespec for samples in -devel

Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	apr-devel - 0.9.6-3.x86_64 requires gcc = 0:4.0.0



Broken deps for ia64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	apr-devel - 0.9.6-3.ia64 requires gcc = 0:4.0.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ia64 requires gjdoc
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	rgmanager - 1.9.31-3.ia64 requires ccs
	p6spy - 1.3-2jpp_1fc.noarch requires regexp



Broken deps for i386
----------------------------------------------------------
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	apr-devel - 0.9.6-3.i386 requires gcc = 0:4.0.0
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	apr-devel - 0.9.6-3.ppc requires gcc = 0:4.0.0



Broken deps for ppc64
----------------------------------------------------------
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ppc64 requires gjdoc
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	apr-devel - 0.9.6-3.ppc64 requires gcc = 0:4.0.0
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	firstboot - 1.3.43-1.noarch requires system-config-display
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp



Broken deps for s390
----------------------------------------------------------
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390 requires gjdoc
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	dhcp - 10:3.0.2-14.FC5.s390 requires kernel >= 0:2.2.18
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	apr-devel - 0.9.6-3.s390 requires gcc = 0:4.0.0
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6



Broken deps for s390x
----------------------------------------------------------
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390x requires gjdoc
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	apr-devel - 0.9.6-3.s390x requires gcc = 0:4.0.0
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	dhcp - 10:3.0.2-14.FC5.s390x requires kernel >= 0:2.2.18
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4





From pp at ee.oulu.fi  Sun Jul 10 11:17:53 2005
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Sun, 10 Jul 2005 14:17:53 +0300
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120923222.2711.87.camel@hush>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
	<1120923222.2711.87.camel@hush>
Message-ID: <20050710111753.GA9442@ee.oulu.fi>

On Sat, Jul 09, 2005 at 05:33:41PM +0200, tony wrote:
> VDR is one that I use. I have messed around with FC4 for a while but it
> looks like after all these years with Redhat I will be moving to ubuntu
> (debian).
Actually VDR works just fine with NPTL. In the latest development
release they even removed the NPTL check and just let it run :). No
problems so far.

(It used to have some linuxthreads assumptions that caused weird problems
with nptl, but they seem to be fixed now). Now if they could make it work
with LANG=en_US.UTF-8 :)

-- 
Pekka Pietikainen



From veillard at redhat.com  Sun Jul 10 11:33:03 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Sun, 10 Jul 2005 07:33:03 -0400
Subject: FireFox Xml Rendering using Xsl is broken in Fedora Core 4
In-Reply-To: <27b710b105071003585cb29c02@mail.gmail.com>
References: <27b710b105071003585cb29c02@mail.gmail.com>
Message-ID: <20050710113303.GH31114@redhat.com>

On Sun, Jul 10, 2005 at 04:28:49PM +0530, Chetan Raj wrote:
> Hi All,
> 
> I use CUnit for my unit-testing framework. (http://cunit.sourceforge.net/)
> 
> It generates an Xml file as an output and uses Xsl to render the same on the 
> browser.
> 
> Now, after moving to Fedora Core 4 from RedHat 9.0, when I open the xml in 
> firefox 1.04 ,I get the following error.
> 
> Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:
> file:///home/chetan//TEST/BIN/CUnit-Run.xsl
> 
> The same was rendering fine in firefox 1.04 on Redhat 9.0.
> 
> I have checked /etc/mime.types and it does have an entry for xsl. I have 
> also added xslt and dtd to the file as show,
> 
> text/xml xsl xml dtd xslt
> 
> 
> Any clues why this doesn't work on Fedora Core 4? And what is the work 
> around?

  Hum, text/xml is for viewing as text, application/xml sounds more appropriate
in taht case.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From hichetu at gmail.com  Sun Jul 10 13:06:05 2005
From: hichetu at gmail.com (Chetan Raj)
Date: Sun, 10 Jul 2005 18:36:05 +0530
Subject: FireFox Xml Rendering using Xsl is broken in Fedora Core 4
In-Reply-To: <20050710113303.GH31114@redhat.com>
References: <27b710b105071003585cb29c02@mail.gmail.com>
	<20050710113303.GH31114@redhat.com>
Message-ID: <27b710b105071006061a00c735@mail.gmail.com>

Hi,

>
> text/xml is for viewing as text, application/xml sounds more appropriate
>

I tried the above, but the result is the same :-(

Thanks,
Chetan


On 7/10/05, Daniel Veillard <veillard at redhat.com> wrote:
> 
> On Sun, Jul 10, 2005 at 04:28:49PM +0530, Chetan Raj wrote:
> > Hi All,
> >
> > I use CUnit for my unit-testing framework. (
> http://cunit.sourceforge.net/)
> >
> > It generates an Xml file as an output and uses Xsl to render the same on 
> the
> > browser.
> >
> > Now, after moving to Fedora Core 4 from RedHat 9.0, when I open the xml 
> in
> > firefox 1.04 ,I get the following error.
> >
> > Error loading stylesheet: An XSLT stylesheet does not have an XML 
> mimetype:
> > file:///home/chetan//TEST/BIN/CUnit-Run.xsl
> >
> > The same was rendering fine in firefox 1.04 on Redhat 9.0.
> >
> > I have checked /etc/mime.types and it does have an entry for xsl. I have
> > also added xslt and dtd to the file as show,
> >
> > text/xml xsl xml dtd xslt
> >
> >
> > Any clues why this doesn't work on Fedora Core 4? And what is the work
> > around?
> 
> Hum, text/xml is for viewing as text, application/xml sounds more 
> appropriate
> in taht case.
> 
> Daniel
> 
> --
> Daniel Veillard | Red Hat Desktop team http://redhat.com/
> veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050710/88815283/attachment.htm>

From caillon at redhat.com  Sun Jul 10 14:12:10 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sun, 10 Jul 2005 10:12:10 -0400
Subject: FireFox Xml Rendering using Xsl is broken in Fedora Core 4
In-Reply-To: <27b710b105071003585cb29c02@mail.gmail.com>
References: <27b710b105071003585cb29c02@mail.gmail.com>
Message-ID: <42D12CBA.1020501@redhat.com>

On 07/10/2005 06:58 AM, Chetan Raj wrote:

> Hi All,
>
> I use CUnit for my unit-testing framework. (http://cunit.sourceforge.net/)
>
> It generates an Xml file as an output and uses Xsl to render the same 
> on the browser.
>
> Now, after moving to Fedora Core 4 from RedHat 9.0, when I open the 
> xml in firefox 1.04 ,I get the following error.
>
> Error loading stylesheet: An XSLT stylesheet does not have an XML 
> mimetype:
> file:///home/chetan//TEST/BIN/CUnit-Run.xsl
>
> The same was rendering fine in firefox 1.04 on Redhat 9.0.
>
> I have checked /etc/mime.types and it does have an entry for xsl. I 
> have also added xslt and dtd to the file as show,
>
> text/xml            xsl xml dtd xslt
>
>
> Any clues why this doesn't work on Fedora Core 4? And what is the work 
> around?

See https://bugs.freedesktop.org/show_bug.cgi?id=2928



From dwmw2 at infradead.org  Sun Jul 10 15:10:35 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 10 Jul 2005 16:10:35 +0100
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120938283.2944.1.camel@localhost.localdomain>
References: <42CEB158.9080308@redhat.com>
	<20050708212457.61f78e39@nausicaa.camperquake.de>
	<42CEDC1F.2030508@redhat.com>
	<1120912029.23706.34.camel@baythorne.infradead.org>
	<1120938283.2944.1.camel@localhost.localdomain>
Message-ID: <1121008235.23706.78.camel@baythorne.infradead.org>

On Sat, 2005-07-09 at 12:44 -0700, Nicholas Miell wrote:
> My understanding was that glibc doesn't care which signedness char has.
> (Although, other libraries may matter. Perhaps a section on not using
> char in library ABIs is in order for dsohowto.pdf)

CHAR_MAX has special meaning in struct lconv. Although I couldn't
actually provoke localeconv() into using CHAR_MAX, even on those locales
for which it apparently ought to.

-- 
dwmw2




From dwmw2 at infradead.org  Sun Jul 10 15:20:44 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 10 Jul 2005 16:20:44 +0100
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120962038.17002.5.camel@localhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<1120962038.17002.5.camel@localhost.localdomain>
Message-ID: <1121008844.23706.83.camel@baythorne.infradead.org>

On Sat, 2005-07-09 at 19:20 -0700, Nicholas Miell wrote:
> This makes me wonder if the IPv6 versions even work. I can't test that,
> but it would be nice if somebody with IPv6 connectivity would take a
> look.

If you have a public IPv4 address, then with about three lines of 'yes
please' in your network configuration you can also have IPv6. 

See http://linux.yyz.us/ipv6-fc2-howto.html

You only really need the 'Simple setup' part, which is trivial to do.
It's the same for FC4 as it was for FC2 (and indeed for RHL6, IIRC).

IPv6 isn't hard, folks.

-- 
dwmw2




From ronny-vlug at vlugnet.org  Sun Jul 10 18:12:48 2005
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Sun, 10 Jul 2005 20:12:48 +0200
Subject: current state of /etc/pki ?
Message-ID: <200507102012.48750.ronny-vlug@vlugnet.org>

Hi,

what is the current state of the /etc/pki layout?
Currently it seems to be only used by mod_ssl, dovecot and sendmail? Other 
stuff in Core/Extras still uses different places to put it's certificates 
(openldap for example).

Only dovecot follows the FHS proposal from John Dennis 
(http://sourceforge.net/mailarchive/forum.php?thread_id=7098065&forum_id=3128).

sendmail has it's key and cert in /etc/pki/tls/certs.

mod_ssl uses /etc/pki/tls/certs (for certs) and /etc/pki/tls/private (for 
keys).

openldap uses /etc/openldap/cacerts (for CA certs) and /usr/share/ssl/certs 
(for server cert and key).


-- 
http://LinuxWiki.org/RonnyBuchmann



From pjones at redhat.com  Sun Jul 10 18:49:57 2005
From: pjones at redhat.com (Peter Jones)
Date: Sun, 10 Jul 2005 14:49:57 -0400
Subject: rawhide report: 20050709 changes
In-Reply-To: <a36b7e2a050710114528351144@mail.gmail.com>
References: <200507091118.j69BIrwV008443@porkchop.devel.redhat.com>
	<a36b7e2a050710114528351144@mail.gmail.com>
Message-ID: <1121021398.4113.6.camel@localhost.localdomain>

On Sun, 2005-07-10 at 13:45 -0500, Justin Conover wrote:

> Uncompressing Linux... Ok, booting the kernel.
> Red Hat nash version 4.2.17 starting
> No volume groups found
> Unable to find volume group "VolGroup00"
> ERROR: /bin/lvm exited abnormally with value 5 ! (pid 353)
> mount: error 6 mounting ext3
> ERROR opening /dev/console!!!!: 2
> error dup2'ing fd of 0 to 0
> error dup2'ing fd 0f 0 to 1
> error dup2'ing fd of 0 to 2
> switchroot: mount failed: 22
> Kernel panic - not syncing: Attempted to kill init!

Are the drivers for your storage controllers making it into the initrd?
-- 
        Peter



From pjones at redhat.com  Sun Jul 10 19:45:00 2005
From: pjones at redhat.com (Peter Jones)
Date: Sun, 10 Jul 2005 15:45:00 -0400
Subject: rawhide report: 20050709 changes
In-Reply-To: <a36b7e2a05071011572a847b8b@mail.gmail.com>
References: <200507091118.j69BIrwV008443@porkchop.devel.redhat.com>
	<a36b7e2a050710114528351144@mail.gmail.com>
	<1121021398.4113.6.camel@localhost.localdomain>
	<a36b7e2a05071011572a847b8b@mail.gmail.com>
Message-ID: <1121024700.4113.12.camel@localhost.localdomain>

On Sun, 2005-07-10 at 13:57 -0500, Justin Conover wrote:
> What is an easy way to check the initrd?  I have an aic7xxx controller
> with 3x36GB scsi on this box.
> 
> dmesg | grep aic
>         <Adaptec aic7899 Ultra160 SCSI adapter>
>         aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>         <Adaptec aic7899 Ultra160 SCSI adapter>
>         aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
> 
> 
>  uname -r
> 2.6.12-1.1400_FC5smp

cd /tmp
zcat /boot/initrd-2.6.12-1.1425_FC5smp.img > initrd-2.6.12-1.1425_FC5smp.img
mkdir initrd-2.6.12-1.1425_FC5smp
cd initrd-2.6.12-1.1425_FC5smp
cpio -dvi < ../initrd-2.6.12-1.1425_FC5smp.img

look in the "lib" directory it'll create there.
-- 
        Peter



From tibbs at math.uh.edu  Sun Jul 10 22:18:24 2005
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Sun, 10 Jul 2005 17:18:24 -0500
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <1120955067.2944.34.camel@localhost.localdomain> (Nicholas
	Miell's message of "Sat, 09 Jul 2005 17:24:27 -0700")
References: <20050709225145.9EF2B1809FC@magilla.sf.frob.com>
	<1120955067.2944.34.camel@localhost.localdomain>
Message-ID: <ufa3bqm485r.fsf@epithumia.math.uh.edu>

>>>>> "NM" == Nicholas Miell <nmiell at comcast.net> writes:

NM> And the answer to that question is: no, there isn't any way,
NM> besides noticing that something dies/behaves erratically/etc. with
NM> NPTL but not with LinuxThreads.

I guess I just didn't understand the nature of the issue.  Is the
situation simply that LinuxThreads and NPTL have the same API but
subtly different semantics?  If so, then my question was pointless,
and only proper testing will show whether there are compatibility
issues.

Thanks for the information.

 - J<



From nmiell at comcast.net  Sun Jul 10 23:15:56 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sun, 10 Jul 2005 16:15:56 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <ufa3bqm485r.fsf@epithumia.math.uh.edu>
References: <20050709225145.9EF2B1809FC@magilla.sf.frob.com>
	<1120955067.2944.34.camel@localhost.localdomain>
	<ufa3bqm485r.fsf@epithumia.math.uh.edu>
Message-ID: <1121037356.2947.0.camel@localhost.localdomain>

On Sun, 2005-07-10 at 17:18 -0500, Jason L Tibbitts III wrote:
> >>>>> "NM" == Nicholas Miell <nmiell at comcast.net> writes:
> 
> NM> And the answer to that question is: no, there isn't any way,
> NM> besides noticing that something dies/behaves erratically/etc. with
> NM> NPTL but not with LinuxThreads.
> 
> I guess I just didn't understand the nature of the issue.  Is the
> situation simply that LinuxThreads and NPTL have the same API but
> subtly different semantics?

NPTL is not bug-for-bug compatible with LinuxThreads. Some brain damaged
apps depend on LinuxThreads bugs.

-- 
Nicholas Miell <nmiell at comcast.net>



From bvest66 at adelphia.net  Mon Jul 11 00:44:03 2005
From: bvest66 at adelphia.net (bvest66 at adelphia.net)
Date: Sun, 10 Jul 2005 20:44:03 -0400
Subject: Error when starting SMB
Message-ID: <30228033.1121042643891.JavaMail.root@web6.mail.adelphia.net>

When I attempt to start samba, I get the following:

Starting SMB services: /etc/init.d/functions: line 83: 3072 Aborted  $nice $*

I am totally out of ideas.


Thanks!


-- 



From zaitcev at redhat.com  Mon Jul 11 03:25:39 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 10 Jul 2005 20:25:39 -0700
Subject: Kernel patch to work around deficiencies in usbmon
Message-ID: <20050710202539.0e244563.zaitcev@redhat.com>

Hi, Dave:

We have usbmon enabled now and it's good, but usb-storage moved away
from under me a little bit. It now maps everything for DMA beforehand,
which makes usbmon to miss the SCSI commands and replies.

I am going to address this problem in usbmon, where it belongs, but
it requires some work which is not done.

What do you think about carrying the attached patch for a few months
(I hope to turn around sooner, but you know how that works!)

-- Pete

diff -urp -X dontdiff linux-2.6.12/drivers/usb/storage/transport.c linux-2.6.12-lem/drivers/usb/storage/transport.c
--- linux-2.6.12/drivers/usb/storage/transport.c	2005-06-21 12:58:48.000000000 -0700
+++ linux-2.6.12-lem/drivers/usb/storage/transport.c	2005-07-06 14:00:30.000000000 -0700
@@ -948,8 +948,9 @@ int usb_stor_Bulk_max_lun(struct us_data
 
 int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us)
 {
-	struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
-	struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap *) us->iobuf;
+	/* Offset into iobuf a little in order to defeat pre-set DMA */
+	struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) (us->iobuf + 4);
+	struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap *) (us->iobuf + 4);
 	unsigned int transfer_length = srb->request_bufflen;
 	unsigned int residue;
 	int result;
@@ -960,7 +961,7 @@ int usb_stor_Bulk_transport(struct scsi_
 	/* Take care of BULK32 devices; set extra byte to 0 */
 	if ( unlikely(us->flags & US_FL_BULK32)) {
 		cbwlen = 32;
-		us->iobuf[31] = 0;
+		((unsigned char *)bcb)[31] = 0;
 	}
 
 	/* set up the command wrapper */



From arjanv at redhat.com  Mon Jul 11 04:07:43 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 11 Jul 2005 06:07:43 +0200
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <ufa3bqm485r.fsf@epithumia.math.uh.edu>
References: <20050709225145.9EF2B1809FC@magilla.sf.frob.com>
	<1120955067.2944.34.camel@localhost.localdomain>
	<ufa3bqm485r.fsf@epithumia.math.uh.edu>
Message-ID: <1121054864.3177.6.camel@laptopd505.fenrus.org>

On Sun, 2005-07-10 at 17:18 -0500, Jason L Tibbitts III wrote:
> >>>>> "NM" == Nicholas Miell <nmiell at comcast.net> writes:
> 
> NM> And the answer to that question is: no, there isn't any way,
> NM> besides noticing that something dies/behaves erratically/etc. with
> NM> NPTL but not with LinuxThreads.
> 
> I guess I just didn't understand the nature of the issue.  Is the
> situation simply that LinuxThreads and NPTL have the same API but
> subtly different semantics?  If so, then my question was pointless,
> and only proper testing will show whether there are compatibility
> issues.

LinuxThreads and NPTL not only have the same API (which is a posix
standard) but also the same ABI. In fact, by default RHL9 and later
(including all Fedora Core releases and RHEL3 and RHEL4) use NPTL by
default for *all* thread using apps, even when they were built against
linuxthreads. You had to go through some hoops to make apps NOT use
NPTL.


Now the "breakage" people talk about is applications depending on bugs
in linuxthreads that got fixed in NPTL.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/d96c9f13/attachment.sig>

From davej at redhat.com  Mon Jul 11 04:56:24 2005
From: davej at redhat.com (Dave Jones)
Date: Mon, 11 Jul 2005 00:56:24 -0400
Subject: Kernel patch to work around deficiencies in usbmon
In-Reply-To: <20050710202539.0e244563.zaitcev@redhat.com>
References: <20050710202539.0e244563.zaitcev@redhat.com>
Message-ID: <20050711045624.GB11311@redhat.com>

On Sun, Jul 10, 2005 at 08:25:39PM -0700, Pete Zaitcev wrote:

Hey Pete,

 > We have usbmon enabled now and it's good, but usb-storage moved away
 > from under me a little bit. It now maps everything for DMA beforehand,
 > which makes usbmon to miss the SCSI commands and replies.
 > 
 > I am going to address this problem in usbmon, where it belongs, but
 > it requires some work which is not done.
 > 
 > What do you think about carrying the attached patch for a few months
 > (I hope to turn around sooner, but you know how that works!)

I'm puzzled (mostly due to my cluelessness in this area)..

 > @@ -948,8 +948,9 @@ int usb_stor_Bulk_max_lun(struct us_data
 >  
 >  int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us)
 >  {
 > -	struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
 > -	struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap *) us->iobuf;
 > +	/* Offset into iobuf a little in order to defeat pre-set DMA */
 > +	struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) (us->iobuf + 4);
 > +	struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap *) (us->iobuf + 4);

I assume this is being done to defeat the check..

    /* we assume that if transfer_buffer isn't us->iobuf then it
     * hasn't been mapped for DMA.  Yes, this is clunky, but it's
     * easier than always having the caller tell us whether the
     * transfer buffer has already been mapped. */
    us->current_urb->transfer_flags =
            URB_ASYNC_UNLINK | URB_NO_SETUP_DMA_MAP;

in usb_stor_msg_common()  ?

Is there any danger of the rest of the code that uses ->iobuf not being
aware that we're now starting 4 bytes in, and running past the end of the
buffer ?

 > @@ -960,7 +961,7 @@ int usb_stor_Bulk_transport(struct scsi_
 >  	/* Take care of BULK32 devices; set extra byte to 0 */
 >  	if ( unlikely(us->flags & US_FL_BULK32)) {
 >  		cbwlen = 32;
 > -		us->iobuf[31] = 0;
 > +		((unsigned char *)bcb)[31] = 0;
 >  	}

If ->iobuf is a ptr to 31 bytes, and bcb starts 4 bytes in, won't this
be writing to the 35th byte of iobuf ?

I'm probably missing something obvious, so hand me a dummys guide to
usb-storage hacking ;)

		Dave



From zaitcev at redhat.com  Mon Jul 11 05:09:48 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 10 Jul 2005 22:09:48 -0700
Subject: Kernel patch to work around deficiencies in usbmon
In-Reply-To: <20050711045624.GB11311@redhat.com>
References: <20050710202539.0e244563.zaitcev@redhat.com>
	<20050711045624.GB11311@redhat.com>
Message-ID: <20050710220948.0881d853.zaitcev@redhat.com>

On Mon, 11 Jul 2005 00:56:24 -0400, Dave Jones <davej at redhat.com> wrote:

> If ->iobuf is a ptr to 31 bytes, and bcb starts 4 bytes in, won't this
> be writing to the 35th byte of iobuf ?

The buffer is 64 bytes big (US_IOBUF_SIZE).

I thought about the coding aspect and shown the patch on linux-usb-devel,
so I expected your decision about the basic idea of carrying a temporary
patch in Fedora kernel, rather than the byte-pushing aspect.

-- Pete



From davej at redhat.com  Mon Jul 11 05:45:28 2005
From: davej at redhat.com (Dave Jones)
Date: Mon, 11 Jul 2005 01:45:28 -0400
Subject: Kernel patch to work around deficiencies in usbmon
In-Reply-To: <20050710220948.0881d853.zaitcev@redhat.com>
References: <20050710202539.0e244563.zaitcev@redhat.com>
	<20050711045624.GB11311@redhat.com>
	<20050710220948.0881d853.zaitcev@redhat.com>
Message-ID: <20050711054528.GC11311@redhat.com>

On Sun, Jul 10, 2005 at 10:09:48PM -0700, Pete Zaitcev wrote:
 > On Mon, 11 Jul 2005 00:56:24 -0400, Dave Jones <davej at redhat.com> wrote:
 > 
 > > If ->iobuf is a ptr to 31 bytes, and bcb starts 4 bytes in, won't this
 > > be writing to the 35th byte of iobuf ?
 > 
 > The buffer is 64 bytes big (US_IOBUF_SIZE).
 > 
 > I thought about the coding aspect and shown the patch on linux-usb-devel,
 > so I expected your decision about the basic idea of carrying a temporary
 > patch in Fedora kernel, rather than the byte-pushing aspect.

Sure, we can carry it for a while.
I'll throw it into the build tomorrow.

		Dave



From zaitcev at redhat.com  Mon Jul 11 05:55:56 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 10 Jul 2005 22:55:56 -0700
Subject: Kernel patch to work around deficiencies in usbmon
In-Reply-To: <20050711054528.GC11311@redhat.com>
References: <20050710202539.0e244563.zaitcev@redhat.com>
	<20050711045624.GB11311@redhat.com>
	<20050710220948.0881d853.zaitcev@redhat.com>
	<20050711054528.GC11311@redhat.com>
Message-ID: <20050710225556.1e65f36e.zaitcev@redhat.com>

On Mon, 11 Jul 2005 01:45:28 -0400, Dave Jones <davej at redhat.com> wrote:

>  > I thought about the coding aspect and shown the patch on linux-usb-devel,
>  > so I expected your decision about the basic idea of carrying a temporary
>  > patch in Fedora kernel, rather than the byte-pushing aspect.
> 
> Sure, we can carry it for a while.
> I'll throw it into the build tomorrow.

I'll let you know when to remove it. Actually, I'll be shooting for 2.6.13
with usbmon fixes, but who knows...

-- Pete



From buildsys at redhat.com  Mon Jul 11 11:37:45 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 11 Jul 2005 07:37:45 -0400
Subject: rawhide report: 20050711 changes
Message-ID: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>

 

 
Updated Packages:

apr-0.9.6-4
-----------
* Mon Jul 11 2005 Florian La Roche <laroche at redhat.com>
- rebuild

gcc-4.0.1-2
-----------
* Sun Jul 10 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.1-2
- update from CVS
  - PRs fortran/17792, fortran/19926, fortran/21257, fortran/21375
- don't run check-ada twice
- create libgna{t,rl}-4.0.so symlinks in the build dir, so that
  check-ada doesn't link against installed libgnat
- add ia64 -fstack-protector support
- fix stack protector test for short arrays

gnome-games-1:2.11.1-1
----------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 1:2.11.1-1
- Update to 2.11.1

kernel-2.6.12-1.1426_FC5
------------------------
* Sun Jul 10 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc2-git3

libxml2-2.6.20-1
----------------
* Mon Jul 11 2005 Daniel Veillard <veillard at redhat.com>
- upstream release 2.6.20 see http://xmlsoft.org/news.html

* Thu Jan 02 2003 Daniel Veillard <veillard at redhat.com>
- integrated drv_libxml2 xml.sax driver from St?phane Bidoul
- provides the new XmlTextReader interfaces based on C# XML APIs

* Wed Oct 23 2002 Daniel Veillard <veillard at redhat.com>
- revamped the spec file, cleaned up some rpm building problems

lv-4.51-6
---------
* Mon Jul 11 2005 Akira TAGOH <tagoh at redhat.com> - 4.51-6
- lv-4.51-162372.patch: silence gcc warning. (#162372)

* Thu Mar 17 2005 Akira TAGOH <tagoh at redhat.com> - 4.51-5
- rebuilt

* Thu Feb 10 2005 Akira TAGOH <tagoh at redhat.com> - 4.51-4
- rebuilt

nautilus-2.11.3-1
-----------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
- Update to 2.11.3

pkgconfig-1:0.18.1-3
--------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 1:0.18.1-3
- Remove unncessary dependencies

Broken deps for s390
----------------------------------------------------------
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390 requires gjdoc
	dhcp - 10:3.0.2-14.FC5.s390 requires kernel >= 0:2.2.18
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for i386
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	rgmanager - 1.9.31-3.ia64 requires ccs
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ia64 requires gjdoc
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0



Broken deps for ppc64
----------------------------------------------------------
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ppc64 requires gjdoc
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	firstboot - 1.3.43-1.noarch requires system-config-display
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	ppc64-utils - 0.7-9.ppc64 requires yaboot



Broken deps for s390x
----------------------------------------------------------
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	dhcp - 10:3.0.2-14.FC5.s390x requires kernel >= 0:2.2.18
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	selinux-policy-strict-sources - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	selinux-policy-strict - 1.25.1-6.noarch requires kernel >= 0:2.6.11-1.1219
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390x requires gjdoc
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5





From kaboom at oobleck.net  Mon Jul 11 15:01:01 2005
From: kaboom at oobleck.net (Chris Ricker)
Date: Mon, 11 Jul 2005 11:01:01 -0400 (EDT)
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120953198.2759.6.camel@locolhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
Message-ID: <Pine.LNX.4.63.0507111045580.32010@urd.oobleck.net>

On Sat, 9 Jul 2005, Michael A. Peters wrote:

> I suppose things like xterm not currently working in ppc doesn't help
> the Fedora cause on that platform, which will be shrinking now that
> Apple has committed to Intel.

xterm doesn't work right on FC4 on any platform

later,
chris



From fedora at camperquake.de  Mon Jul 11 15:09:07 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 11 Jul 2005 17:09:07 +0200
Subject: A quick look at the yum mirrorlists
In-Reply-To: <Pine.LNX.4.63.0507111045580.32010@urd.oobleck.net>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
	<Pine.LNX.4.63.0507111045580.32010@urd.oobleck.net>
Message-ID: <20050711170907.1987c8e9@nausicaa.camperquake.de>

Hi.

Chris Ricker <kaboom at oobleck.net> wrote:

> xterm doesn't work right on FC4 on any platform

The magic words are "XTerm*eightBitInput: true" in your
~/.Xresources

Funny enough this is needed on my iBook, but not on my
x86 machines.

-- 
Life is NOT like a box of chocolates.
Any individuals persisting on spreading this rumour will be executed.



From kaboom at oobleck.net  Mon Jul 11 16:31:32 2005
From: kaboom at oobleck.net (Chris Ricker)
Date: Mon, 11 Jul 2005 12:31:32 -0400 (EDT)
Subject: A quick look at the yum mirrorlists
In-Reply-To: <20050711170907.1987c8e9@nausicaa.camperquake.de>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
	<Pine.LNX.4.63.0507111045580.32010@urd.oobleck.net>
	<20050711170907.1987c8e9@nausicaa.camperquake.de>
Message-ID: <Pine.LNX.4.63.0507111230480.32010@urd.oobleck.net>

On Mon, 11 Jul 2005, Ralf Ertzinger wrote:

> Hi.
> 
> Chris Ricker <kaboom at oobleck.net> wrote:
> 
> > xterm doesn't work right on FC4 on any platform
> 
> The magic words are "XTerm*eightBitInput: true" in your
> ~/.Xresources

For PPC, yes

I was actually referring to the backspace borkage in vim, though

*ttyModes: erase ^?

later,
chris



From fedora at camperquake.de  Mon Jul 11 16:37:54 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 11 Jul 2005 18:37:54 +0200
Subject: A quick look at the yum mirrorlists
In-Reply-To: <Pine.LNX.4.63.0507111230480.32010@urd.oobleck.net>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
	<Pine.LNX.4.63.0507111045580.32010@urd.oobleck.net>
	<20050711170907.1987c8e9@nausicaa.camperquake.de>
	<Pine.LNX.4.63.0507111230480.32010@urd.oobleck.net>
Message-ID: <20050711183754.785f6801@nausicaa.camperquake.de>

Hi.

Chris Ricker <kaboom at oobleck.net> wrote:

> I was actually referring to the backspace borkage in vim, though
> 
> *ttyModes: erase ^?

I have to admit that I have not noticed anything wrong with my
backspace in vi.

-- 
Disservice: It takes months to find a customer, but only seconds to lose
one. The good news is that we should run out of them in no time.
                                      -- Despair Inc. calendar, April 2001



From lfarkas at bppiac.hu  Mon Jul 11 18:02:10 2005
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Mon, 11 Jul 2005 20:02:10 +0200
Subject: how to notify package maintaner?
Message-ID: <42D2B422.6050506@bppiac.hu>

hi,
is there any standard way to notify any package (core or extras) 
maintaner that there is new upstream version of bug/security fix of a 
given package? imho it'd be a general and useful think to add somewhere 
eg somewhere on fedora homepage an automatic from which select the 
current maintaner and send him/her a mail.
yours.

-- 
   Levente                               "Si vis pacem para bellum!"



From johnp at redhat.com  Mon Jul 11 18:06:18 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 11 Jul 2005 14:06:18 -0400
Subject: how to notify package maintaner?
In-Reply-To: <42D2B422.6050506@bppiac.hu>
References: <42D2B422.6050506@bppiac.hu>
Message-ID: <1121105178.24890.46.camel@remedyz.boston.redhat.com>

File a bug report on the component is the best way to get the
maintainer's attention.

On Mon, 2005-07-11 at 20:02 +0200, Farkas Levente wrote:
> hi,
> is there any standard way to notify any package (core or extras) 
> maintaner that there is new upstream version of bug/security fix of a 
> given package? imho it'd be a general and useful think to add somewhere 
> eg somewhere on fedora homepage an automatic from which select the 
> current maintaner and send him/her a mail.
> yours.
> 
> -- 
>    Levente                               "Si vis pacem para bellum!"

-- 
John (J5) Palmieri <johnp at redhat.com>



From jos at xos.nl  Mon Jul 11 18:07:31 2005
From: jos at xos.nl (Jos Vos)
Date: Mon, 11 Jul 2005 20:07:31 +0200
Subject: how to notify package maintaner?
In-Reply-To: <42D2B422.6050506@bppiac.hu>;
	from lfarkas@bppiac.hu on Mon, Jul 11, 2005 at 08:02:10PM +0200
References: <42D2B422.6050506@bppiac.hu>
Message-ID: <20050711200731.A1565@xos037.xos.nl>

On Mon, Jul 11, 2005 at 08:02:10PM +0200, Farkas Levente wrote:

> is there any standard way to notify any package (core or extras) 
> maintaner that there is new upstream version of bug/security fix of a 
> given package? imho it'd be a general and useful think to add somewhere 
> eg somewhere on fedora homepage an automatic from which select the 
> current maintaner and send him/her a mail.

I think you should do this via Bugzilla: if it is a bug, file it and
mention the new version.  If it is a new feature you need from a new
version, add a RFE.  In this way, everybody can see it and there is
a track record of the problem, the maintainer's response, etc.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From aoliva at redhat.com  Mon Jul 11 18:40:11 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 11 Jul 2005 15:40:11 -0300
Subject: rawhide report: 20050711 changes
In-Reply-To: <a36b7e2a0507110647338deb08@mail.gmail.com>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<a36b7e2a0507110647338deb08@mail.gmail.com>
Message-ID: <oru0j1xk38.fsf@livre.redhat.lsd.ic.unicamp.br>

On Jul 11, 2005, Justin Conover <justin.conover at gmail.com> wrote:

> Another busted kernel for me, why aren't they including aic7xxx and
> "scsi stuff" ;)

Could be a bug in mkinitrd, or some changes in /proc, or something
entirely different.  First off, try to create the initrd by hand
passing mkinitrd the needed --with commands.  If that works, start
investigating why mkinitrd doesn't figure out it needs the drivers you
need.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From riel at redhat.com  Mon Jul 11 21:07:58 2005
From: riel at redhat.com (Rik van Riel)
Date: Mon, 11 Jul 2005 17:07:58 -0400 (EDT)
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <pan.2005.07.09.13.33.32.896292@plan99.net>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
Message-ID: <Pine.LNX.4.61.0507111707230.19065@chimarrao.boston.redhat.com>

On Sat, 9 Jul 2005, Mike Hearn wrote:

> Most of the old Loki games no longer work, for various reasons, NPTL 
> amongst them.

The Loki games I have appear to be statically linked, so
glibc shouldn't have any influence on those.

-- 
The Theory of Escalating Commitment: "The cost of continuing mistakes is
borne by others, while the cost of admitting mistakes is borne by yourself."
  -- Joseph Stiglitz, Nobel Laureate in Economics



From caillon at redhat.com  Mon Jul 11 21:18:40 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 11 Jul 2005 17:18:40 -0400
Subject: how to notify package maintaner?
In-Reply-To: <42D2B422.6050506@bppiac.hu>
References: <42D2B422.6050506@bppiac.hu>
Message-ID: <42D2E230.6060109@redhat.com>

On 07/11/2005 02:02 PM, Farkas Levente wrote:

> hi,
> is there any standard way to notify any package (core or extras) 
> maintaner that there is new upstream version of bug/security fix of a 
> given package? imho it'd be a general and useful think to add 
> somewhere eg somewhere on fedora homepage an automatic from which 
> select the current maintaner and send him/her a mail.
> yours.

Some package maintainers have upwards of 50 packages they maintain, and 
can't possibly produce RPMs instantly.  There are sometimes issues where 
things don't build, etc. because of other library changes that we must 
deal with that the upstream authors may not be aware of yet.  
Additionally, many maintainers are on mailing lists that announce when 
new versions are out; some (such as yours truly) are even on release 
teams for their packages.  So, chances are the packager knows, but just 
has been unable to get around to it.  If there is a package that has 
been languishing behind for several months, or maybe weeks, it might be 
wise to file a bug then.  But flooding bugzilla and developer e-mail 
with generic package upgrade requests is going to annoy many packagers 
very quickly.



From chasd at silveroaks.com  Mon Jul 11 22:36:06 2005
From: chasd at silveroaks.com (chasd at silveroaks.com)
Date: Mon, 11 Jul 2005 17:36:06 -0500
Subject: A quick look at the yum mirrorlists
In-Reply-To: <20050710022058.F3C9A737DA@hormel.redhat.com>
References: <20050710022058.F3C9A737DA@hormel.redhat.com>
Message-ID: <0cb50fed9dfd0b265ea965511a42a3ea@silveroaks.com>

> On Sat, 2005-07-09 at 19:20 -0400, Daniel Veillard wrote:
>
>>
>>   How many are using ppc ? I didn't had much space until a few hours 
>> ago
>> to add it, but I'm still pondering the effectiveness of the use of the
>> disk space. Apparently I'm not the only one,
>
> I use Fedora on PPC - but I'm the only one (outside of fedora user
> lists) that I personally know of.
>
> Most ppc people I know use YellowDog or gentoo.

I will be migrating my YDL machines to FC4 PPC.

1)
I use FC on x86, so using same on PPC makes sense
2)
YDL security updates are slow to appear or missing in many cases
3)
I already compile SRPMS of FC on YDL installs for some apps/features

Over the years I've migrated some machines MkLinux->LinuxPPC->YDL, why 
not FC too ;)

> which will be shrinking now that
> Apple has committed to Intel.

Interesting question, is FC on PPC likely to suffer the same as ia64 
and SPARC?
Or superseded by ppc64?

Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/
824 17th Street, Moline  IL  61265



From veillard at redhat.com  Mon Jul 11 23:13:40 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Mon, 11 Jul 2005 19:13:40 -0400
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1120953198.2759.6.camel@locolhost.localdomain>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
Message-ID: <20050711231340.GD7527@redhat.com>

On Sat, Jul 09, 2005 at 04:53:18PM -0700, Michael A. Peters wrote:
> On Sat, 2005-07-09 at 19:20 -0400, Daniel Veillard wrote:
> >   How many are using ppc ? I didn't had much space until a few hours ago
> > to add it, but I'm still pondering the effectiveness of the use of the
> > disk space. Apparently I'm not the only one, 
[...]
> Still though - if a mirror doesn't have ppc, it shouldn't be part of a
> mirror list used by the ppc platform.

  I added ppc to fr.rpmfind.net. One interesting point of yum
is that it should be relatively easy to extract statistics from http
logs for things like:
   - relative use of different arches
   - most updated packages
   - are extras packages sources used
   - which extras are most popular
absolute values may be a bit hard to get since people will use local
mirrors, but there may be useful informations to gather still.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From lfsjeremy at gmail.com  Mon Jul 11 23:40:10 2005
From: lfsjeremy at gmail.com (Jeremy Utley)
Date: Mon, 11 Jul 2005 16:40:10 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <Pine.LNX.4.61.0507111707230.19065@chimarrao.boston.redhat.com>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
	<Pine.LNX.4.61.0507111707230.19065@chimarrao.boston.redhat.com>
Message-ID: <3aaec884050711164038af9b58@mail.gmail.com>

Interesting thread on the removal of LinuxThreads - I myself have been
playing with NPTL only systems for quite some time (well over a year
now) - in all my time working with them, I only personally found one
thing that broke with NPTL libs - and it was a compile-time bug, not a
run-time bug - that being the compilation of a UML (User Mode Linux)
kernel.  Now, mind you, I have not tried to do so in quite some time,
but it used to be that when compiling a UML kernel on an NPTL-only
system (NPTL libpthread in /lib, no /lib/tls), the compile would fail.
 However, a kernel compiled on an older LT system, and the binary
transferred over to an NPTL system, would work perfectly.

Just pointing out another place where this may pose a problem.

Jeremy



From rodd at clarkson.id.au  Tue Jul 12 00:31:03 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 12 Jul 2005 10:31:03 +1000
Subject: rawhide report: 20050711 changes
In-Reply-To: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
Message-ID: <1121128263.7251.7.camel@goose>

On Mon, 2005-07-11 at 07:37 -0400, Build System wrote:

> nautilus-2.11.3-1
> -----------------
> * Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
> - Update to 2.11.3

Ah, this might be a dumb question, but what happened to the Open
Terminal option when right clicking on the desktop in Gnome?

Has this been intentionally removed?  If it has, can the user re-enable
it on a user by user basis.  This is about the only option I use in this
context menu, so it's loss is a great usability issue for me.  I can
however see how the average user may not need it, but I'd still like to
think that users who do want it might be able to have it.

Of course it might just be an accident, in which case I look forward to
it's return soon (and if it is a mistake, I'll bugzilla it).


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From ivazquez at ivazquez.net  Tue Jul 12 01:14:57 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Mon, 11 Jul 2005 21:14:57 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121128263.7251.7.camel@goose>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose>
Message-ID: <1121130897.4423.10.camel@ignacio.lan>

On Tue, 2005-07-12 at 10:31 +1000, Rodd Clarkson wrote:
> On Mon, 2005-07-11 at 07:37 -0400, Build System wrote:
> 
> > nautilus-2.11.3-1
> > -----------------
> > * Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
> > - Update to 2.11.3
> 
> Ah, this might be a dumb question, but what happened to the Open
> Terminal option when right clicking on the desktop in Gnome?
> 
> Has this been intentionally removed?  If it has, can the user re-enable
> it on a user by user basis.  This is about the only option I use in this
> context menu, so it's loss is a great usability issue for me.  I can
> however see how the average user may not need it, but I'd still like to
> think that users who do want it might be able to have it.
> 
> Of course it might just be an accident, in which case I look forward to
> it's return soon (and if it is a mistake, I'll bugzilla it).

This change has been planned for a while now. Just add a launcher to a
panel.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/ab9b744a/attachment.sig>

From rodd at clarkson.id.au  Tue Jul 12 01:28:59 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 12 Jul 2005 11:28:59 +1000
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121130897.4423.10.camel@ignacio.lan>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
Message-ID: <1121131739.7251.15.camel@goose>

On Mon, 2005-07-11 at 21:14 -0400, Ignacio Vazquez-Abrams wrote:
> On Tue, 2005-07-12 at 10:31 +1000, Rodd Clarkson wrote:
> > On Mon, 2005-07-11 at 07:37 -0400, Build System wrote:
> > 
> > > nautilus-2.11.3-1
> > > -----------------
> > > * Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
> > > - Update to 2.11.3
> > 
> > Ah, this might be a dumb question, but what happened to the Open
> > Terminal option when right clicking on the desktop in Gnome?
> > 
> > Has this been intentionally removed?  If it has, can the user re-enable
> > it on a user by user basis.  This is about the only option I use in this
> > context menu, so it's loss is a great usability issue for me.  I can
> > however see how the average user may not need it, but I'd still like to
> > think that users who do want it might be able to have it.
> > 
> > Of course it might just be an accident, in which case I look forward to
> > it's return soon (and if it is a mistake, I'll bugzilla it).
> 
> This change has been planned for a while now. Just add a launcher to a
> panel.

I have a launcher on the panel, but to be brutally honest, I don't want
to have to travel to to top of the screen each time I want to launch a
terminal.  On a 1920x1200 screen, that top panel is a long way away when
you're using a trackpad style laptop mouse.

You could argue the same could be done with all the other options in
this menu and we could just do away with the menu. ;-]  At least with
the gnome-terminal option, the resulting terminal is always visible.  On
the other hand, the Create Folder option often creates a folder that
can't be seen as it's covered by windows, so it's arguably a little
pointless (this is probably a bug worth filing (new folder should always
appear on desktop where it's visible).

Can someone point to the thread where removing gnome-terminal was
discussed?

I know this seems a little
my-workflow-isn't-the-same-after-this-change-so-this-isn't-acceptable
but there are plenty of people who use terminals in gnome and I'm sure
that more than a few of them launch them this way.  A gconf variable I
can set to re-add it to the menu would be more than acceptable.


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From shiva at sewingwitch.com  Tue Jul 12 01:50:48 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Mon, 11 Jul 2005 18:50:48 -0700
Subject: new in 2005-7-9 glibc: no more LinuxThreads
In-Reply-To: <Pine.LNX.4.61.0507111707230.19065@chimarrao.boston.redhat.com>
References: <42CEB158.9080308@redhat.com>
	<pan.2005.07.09.13.33.32.896292@plan99.net>
	<Pine.LNX.4.61.0507111707230.19065@chimarrao.boston.redhat.com>
Message-ID: <3EC76613BF0E59B79AFB2A06@[10.169.6.233]>

--On Monday, July 11, 2005 5:07 PM -0400 Rik van Riel <riel at redhat.com> 
wrote:

> The Loki games I have appear to be statically linked, so
> glibc shouldn't have any influence on those.

I'm using tribes2d.dynamic for my T2 game servers running on FC2. Seems to 
work ok.

Once upon a time I recall having to use one of those KERNEL_ASSUME 
environment variables, but I don't see it in my current script. An old 
script has this:

export LD_ASSUME_KERNEL=2.2.5

I think this had something to do with a change to how saving the FPU state 
was done. It doesn't appear to be needed now.

With the advent of more multi-core CPU's, I expect to see more game server 
binaries make use of threading. There's some now in Battlefield 2's server.




From jnansi at gmail.com  Tue Jul 12 01:59:47 2005
From: jnansi at gmail.com (Jatin Nansi)
Date: Tue, 12 Jul 2005 07:29:47 +0530
Subject: nptl configuration
In-Reply-To: <1120914536.7035.0.camel@localhost.localdomain>
References: <1120914536.7035.0.camel@localhost.localdomain>
Message-ID: <53d4ffb8050711185956148c2c@mail.gmail.com>

on all recent fedora distros, /lib/libc.so.6 is the old linux threads
implementation - maintained for backward compatibility purposes. 
/lib/tls/libc.so.6 is the nptl implementation. all applications using
posix threads will be linked to this version automatically, unless u
explicitly link to the former. you dont need to do anything special to
use nptl. to check use ldd on a FC binary using threads.

On 7/9/05, divij bhatt <divij at innomedia.soft.net> wrote:
> Hi,
>     I want to know that how can i configure nptl on my linux 2.6.10
> kernel.I am confused little bit because when  I give
> the command:->getconf GNU_LIBPTHREAD_VERSION it is returning the value
> nptl-0.61 but when i am giving the command:->
> /lib/libc.so.6 where it is giving following output:->linuxthreads-0.10
> by Xavier Leroy instead of
> Native POSIX Threads Library by Ulrich Drepper et al I am using the gcc
> version 3.3.3 and Thread Model:-POSIX But when I
> am giving:->/lib/tls/libc.so.6 it is giving:->Native POSIX Threads
> Library by Ulrich Drepper et al So tell me whether it
> is working or not.
> 
> Thanks
> Divij Kumar Bhatt
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
Jatin Nansi

It's not that I'm so smart, it's just that I stay with problems longer.
-- Einstein



From lamont at gurulabs.com  Tue Jul 12 02:03:26 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Mon, 11 Jul 2005 20:03:26 -0600
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121130897.4423.10.camel@ignacio.lan>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>
Message-ID: <200507112003.31480.lamont@gurulabs.com>

On Monday 11 July 2005 07:14pm, Ignacio Vazquez-Abrams wrote:
> On Tue, 2005-07-12 at 10:31 +1000, Rodd Clarkson wrote:
> > On Mon, 2005-07-11 at 07:37 -0400, Build System wrote:
> > > nautilus-2.11.3-1
> > > -----------------
> > > * Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
> > > - Update to 2.11.3
> >
> > Ah, this might be a dumb question, but what happened to the Open
> > Terminal option when right clicking on the desktop in Gnome?
> >
> > Has this been intentionally removed?  If it has, can the user re-enable
> > it on a user by user basis.  This is about the only option I use in this
> > context menu, so it's loss is a great usability issue for me.  I can
> > however see how the average user may not need it, but I'd still like to
> > think that users who do want it might be able to have it.
> >
> > Of course it might just be an accident, in which case I look forward to
> > it's return soon (and if it is a mistake, I'll bugzilla it).
>
> This change has been planned for a while now. Just add a launcher to a
> panel.

Where was that discussion?

I teach many classes and proctor certification exams for Red Hat. Almost 
invariably, there are always some students in the class that did not know 
about the "Open Terminal" context menu option.  Once they see it, almost 
every single one is quite excited about it and starts using it all the time 
since it is a whole lot more convenient.

Personally, I prefer KDE, but use both Gnome & KDE regularly.  I wish there 
was an option to launch Konsole from such a context menu in KDE.  I use it 
all the time on Gnome.  From my first hand experience, I would have to say 
that most people who know about it use it.

It seems almost stupid (please, don't flame me, I'm not impugning anyone) to 
me to remove such a useful option.  What does it hurt to have it there?  Are 
we running out of space in the Nautilus context menu array or something?  
Give us some good reasons why that should go.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/457d8349/attachment.sig>

From ivazquez at ivazquez.net  Tue Jul 12 02:41:13 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Mon, 11 Jul 2005 22:41:13 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121131739.7251.15.camel@goose>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121131739.7251.15.camel@goose>
Message-ID: <1121136073.4423.15.camel@ignacio.lan>

On Tue, 2005-07-12 at 11:28 +1000, Rodd Clarkson wrote:
> Can someone point to the thread where removing gnome-terminal was
> discussed?

On Mon, 2005-07-11 at 20:03 -0600, Lamont R. Peterson wrote: 
> Where was that discussion?

http://bugzilla.gnome.org/show_bug.cgi?id=131792

OTOH, Desktop | Preferences | Keyboard Shortcuts | Desktop | Run a
terminal

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/516f2c32/attachment.sig>

From vonbrand at inf.utfsm.cl  Tue Jul 12 02:38:59 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Mon, 11 Jul 2005 22:38:59 -0400
Subject: rawhide report: 20050711 changes 
In-Reply-To: Message from Rodd Clarkson <rodd@clarkson.id.au> 
	of "Tue, 12 Jul 2005 10:31:03 +1000." <1121128263.7251.7.camel@goose> 
Message-ID: <200507120238.j6C2cxFs030484@laptop11.inf.utfsm.cl>

Rodd Clarkson <rodd at clarkson.id.au> wrote:
> On Mon, 2005-07-11 at 07:37 -0400, Build System wrote:
> 
> > nautilus-2.11.3-1
> > -----------------
> > * Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
> > - Update to 2.11.3
> 
> Ah, this might be a dumb question, but what happened to the Open
> Terminal option when right clicking on the desktop in Gnome?

I second that! That is the /only/ use I ever gave to that particular menu.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From dimi at lattica.com  Tue Jul 12 03:39:33 2005
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 11 Jul 2005 23:39:33 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121130897.4423.10.camel@ignacio.lan>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
Message-ID: <1121139573.11210.19.camel@dimi>

On Mon, 2005-07-11 at 21:14 -0400, Ignacio Vazquez-Abrams wrote:
> 
> This change has been planned for a while now. Just add a launcher to a
> panel.

Oh, not this again! We turn a perfectly useful thing in another
"configure yourself" answer. Are we going back to the infinitely
configurable but useless desktop?

Why? Out of the entire GNOME menu, that was the most useful feature
by an order of magnitude (for me).

It is really sad that such important changes are taken in such a
haphazard manner, sacrificing usefulness to some misguided grand
vision of usability.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mlauterbach at mail.wtamu.edu  Mon Jul 11 22:56:36 2005
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Mon, 11 Jul 2005 17:56:36 -0500
Subject: rawhide report: 20050711 changes
In-Reply-To: <200507112003.31480.lamont@gurulabs.com>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<200507112003.31480.lamont@gurulabs.com>
Message-ID: <1121122596.21980.4.camel@amd64.mattlauterbach.com>

On Mon, 2005-07-11 at 20:03 -0600, Lamont R. Peterson wrote:
> Personally, I prefer KDE, but use both Gnome & KDE regularly.  I wish there 
> was an option to launch Konsole from such a context menu in KDE.  I use it 
> all the time on Gnome.  From my first hand experience, I would have to say 
> that most people who know about it use it.
> 
Have you checked KDE lately?  I have Konsole on right-click in FC4's KDE
3.4.1.  It's a good thing.

Matthew E. Lauterbach



From jspaleta at gmail.com  Tue Jul 12 04:24:09 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 12 Jul 2005 00:24:09 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121139573.11210.19.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
Message-ID: <604aa79105071121247b3616b7@mail.gmail.com>

On 7/11/05, Dimi Paun <dimi at lattica.com> wrote:
> Why? Out of the entire GNOME menu, that was the most useful feature
> by an order of magnitude (for me).

(for you)  sums it up.  Perhaps... just perhaps... you aren't inside
the target audience that Gnome is designing for. I too use the
terminal all the time. But you know what.... i know i'm not the target
audience that that GNOME is aiming their UI design towards.  I realize
what I do on a regular basis is well outside the curve for any
hypothetical user profile Gnome is using to design their UI.  Not only
that, but I also realize that my experience with Unix systems has
inspired an irrational craving for the cmdline. And I'm perfectly okay
with the fact that GNOME is not designed explicitly for me... because
it it was.. it would be a horrible unusable mess for 90% of the rest
of humanity.

My wife on the other hand, uses her GNOME desktop in a vastly
different way... a way that is probably is much more aligned with the
usage scenario the gnome developers are aiming their design towards. I
have never,ever....ever  seen her open up a terminal to do any
end-user task on her desktop.    The only time a terminal is opened up
on that fedora desktop is when something is misbehaving, and I stick
my nose in to try to diagnose the problem.

I think anyone with 3 working braincells who is making even a
half-hearted effort at keeping up with the momentum of gnome
development isn't terribly shocked at the change in the menu to remove
the terminal.  While sttupifyingly easy point-and-click access to a
terminal seems a worthwhile convience for the technically elite or for
the old unix dogs, a terminal certainly shouldn't be a prominently
placed tool for the target audience that Gnome is being  designed for.
  Its pretty brave of Gnome to actually say mainstream users of their
desktop do not need quick access to a terminal to get typical
workloads done... but I can't disagree with the goal. Mainstream
office and home users of a modern computer desktop environment should
not need to use the terminal so oftern that the terminal should be in
the main desktop menu.

>It is really sad that such important changes are taken in such a
>haphazard manner, sacrificing usefulness to some misguided grand
>vision of usability

This isn't an important change. You are talking about the removal of a
connivance feature to open up a terminal via a mouse click. C'mon....
lets be serious. The people who live inside a terminal can just as
easily use the provided keyboard shortcut mechanism to launch a
terminal. If anything its a bit ironic that terminal-junkies are
screaming about drop down desktop menus instead of screaming about
defining default keyboard shortcuts. Real terminal junkies never have
viewable desktop real estate to even get a right click menu.

-jef"card carrying member of Terminal Emulators Anonymous.... I can
stop using a terminal anytime a want to.. I just don't want to"spaleta



> It is really sad that such important changes are taken in such a
> haphazard manner, sacrificing usefulness to some misguided grand
> vision of usability.



From dimi at lattica.com  Tue Jul 12 04:34:56 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 12 Jul 2005 00:34:56 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <604aa79105071121247b3616b7@mail.gmail.com>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
Message-ID: <1121142896.11210.36.camel@dimi>

On Tue, 2005-07-12 at 00:24 -0400, Jeff Spaleta wrote:
>   Its pretty brave of Gnome to actually say mainstream users of their
> desktop do not need quick access to a terminal to get typical
> workloads done... but I can't disagree with the goal. Mainstream
> office and home users of a modern computer desktop environment should
> not need to use the terminal so oftern that the terminal should be in
> the main desktop menu.

This is a nice way to put it. We're nowhere close to "not require access
to the terminal", and I can't possibly see how this helps anyone.

Like it or not, but by and large the Linux audience is fairly technical,
and they do use a terminal. Why make it harder for most of the users?

This is the sort of 'brave' move that reminds me (at a much smaller
scale, I agree) to the spatial nautilus business. I haven't met a single
person that wasn't upset by that change. And that was shoved down
people's throats rather unceremoniously. 

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jkeating at j2solutions.net  Tue Jul 12 04:37:29 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 11 Jul 2005 21:37:29 -0700
Subject: No more right click terminal
Message-ID: <1121143049.3521.16.camel@localhost.localdomain>

I would really like to open this up to the discussion for the users and
developers of Fedora.  This feature is very ingrained in a lot of our
muscle memories, deeply embedded in our internal and external
documentation for not just end users but entry level admins, group
admins, and a myriad of folks that really do have a use for the
terminal.  Sure you can just as easily get to it by selecting it from a
menu, so that actually goes in my favor.  If we're trying to 'protect'
the user, why have it in the menu at all?  If the end user that Gnome
seems to care about won't notice, why not leave it so that the people
who have a clue and have the capability of helping out don't get pissed
off by yet another 'lets break history in favor of some "usability" we
think is right for the fabled holy grail of an end user'.

This is yet another move in a long history of Gnome moves that makes me
wish somebody forked gnome a while ago and removed all these stupid
'save the end user from themselves' changes.  For god sakes, make a 'end
user safe' UI that has all these things in it, and then make a 'real
user' UI that actually allows work to be done in the way that it has
been done for years.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/a6b86a44/attachment.sig>

From skvidal at phy.duke.edu  Tue Jul 12 04:40:46 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 12 Jul 2005 00:40:46 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121142896.11210.36.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>
Message-ID: <1121143246.10435.9.camel@cutter>

On Tue, 2005-07-12 at 00:34 -0400, Dimi Paun wrote:
> On Tue, 2005-07-12 at 00:24 -0400, Jeff Spaleta wrote:
> >   Its pretty brave of Gnome to actually say mainstream users of their
> > desktop do not need quick access to a terminal to get typical
> > workloads done... but I can't disagree with the goal. Mainstream
> > office and home users of a modern computer desktop environment should
> > not need to use the terminal so oftern that the terminal should be in
> > the main desktop menu.
> 
> This is a nice way to put it. We're nowhere close to "not require access
> to the terminal", and I can't possibly see how this helps anyone.
> 
> Like it or not, but by and large the Linux audience is fairly technical,
> and they do use a terminal. Why make it harder for most of the users?
> 
> This is the sort of 'brave' move that reminds me (at a much smaller
> scale, I agree) to the spatial nautilus business. I haven't met a single
> person that wasn't upset by that change. And that was shoved down
> people's throats rather unceremoniously. 

My name is seth vidal. I was not upset by spatial nautilus.

pleased to meet you.

-sv




From skvidal at phy.duke.edu  Tue Jul 12 04:43:32 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 12 Jul 2005 00:43:32 -0400
Subject: No more right click terminal
In-Reply-To: <1121143049.3521.16.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
Message-ID: <1121143412.10435.13.camel@cutter>

On Mon, 2005-07-11 at 21:37 -0700, Jesse Keating wrote:
> I would really like to open this up to the discussion for the users and
> developers of Fedora.  This feature is very ingrained in a lot of our
> muscle memories, deeply embedded in our internal and external
> documentation for not just end users but entry level admins, group
> admins, and a myriad of folks that really do have a use for the
> terminal.  Sure you can just as easily get to it by selecting it from a
> menu, so that actually goes in my favor.  If we're trying to 'protect'
> the user, why have it in the menu at all?  If the end user that Gnome
> seems to care about won't notice, why not leave it so that the people
> who have a clue and have the capability of helping out don't get pissed
> off by yet another 'lets break history in favor of some "usability" we
> think is right for the fabled holy grail of an end user'.
> 
> This is yet another move in a long history of Gnome moves that makes me
> wish somebody forked gnome a while ago and removed all these stupid
> 'save the end user from themselves' changes.  For god sakes, make a 'end
> user safe' UI that has all these things in it, and then make a 'real
> user' UI that actually allows work to be done in the way that it has
> been done for years.

it's not about making it safe, not in every case. It is about
simplifying the applications. There's a lot to it - but having items on
hidden menus is, in general, a bad idea.

But if you want to affect change in this area please join the
desktop-devel-list for gnome and discuss it. But bringing it up as a
fedora-devel issue isn't really going to help.

-sv




From jkeating at j2solutions.net  Tue Jul 12 04:51:20 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 11 Jul 2005 21:51:20 -0700
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121142896.11210.36.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>
Message-ID: <1121143880.3521.18.camel@localhost.localdomain>

On Tue, 2005-07-12 at 00:34 -0400, Dimi Paun wrote:
> This is the sort of 'brave' move that reminds me (at a much smaller
> scale, I agree) to the spatial nautilus business. I haven't met a
> single
> person that wasn't upset by that change. And that was shoved down
> people's throats rather unceremoniously. 

I like that we can easily turn it off, and get back to a tree view for
everything.  Of course this may be removed soon because it is too much
code to modify and no end user in their right mind would ever need to
see a tree.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/d059a688/attachment.sig>

From jspaleta at gmail.com  Tue Jul 12 05:08:58 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 12 Jul 2005 01:08:58 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121142896.11210.36.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>
Message-ID: <604aa791050711220855201496@mail.gmail.com>

On 7/12/05, Dimi Paun <dimi at lattica.com> wrote:
> This is a nice way to put it. We're nowhere close to "not require access
> to the terminal", and I can't possibly see how this helps anyone.

It helps.. because now... everyone who is relying on the terminal gets
to go back and try to make a list of reasons they are using a
terminal... or telling other people to use a terminal.. and categorize
the reasons why.

Is the action you are doing in a terminal.. simply because you are use
to the cmdline.. and refuse to actually use the desktop components?  I
know i open a terminal simply because I'm use to driving around my
filesystem in bash. This is not however something I expect normal
people to want to do.

Is the task a specialized system admin task that you would expect to
only perform as a trained admin or is this a typical task a home user
would be doing to admin their own stand-alone box?  configuring gfs is
clearly not something I would expect a novice to be able to do without
a terminal, nor would i expect a novice user/admin to need to screw
with it.

Is the task you are performing really a developer task?  

Or, are you opening a terminal explicitly to workaround perceived
brokenness or un-intuitive aspects of the desktop design?

This last category of items is really the big issue for me.  This list
of items here needs to be vanishingly small to make prominent location
of the terminal appear reasonable to me.
But I don't have perspective, I use a terminal for pretty much
everything.. well other than gmail.  I would be very interested in
knowing what people put in this last category, the "open a terminal
workaround perceived brokenness or un-intuitive aspects of the
desktop" category.
And to see what the plans are to resolve those specific items in the
gnome development plan.

> 
> Like it or not, but by and large the Linux audience is fairly technical,
> and they do use a terminal. Why make it harder for most of the users?

Because I do not believe panding to technical users, helps the mission
to serve a wider community.  Building a system that has defaults that
caters to the technical, is myopic. The technically inclined by
definition, know how to dig in and reconfigure.  Gnome's mission isn't
to optimize for the technical elite.  This is a rediculously minor
feature. The terminal isn't going away, its just not being given
special treatment anymore compared to other applications.  I would
however like to see a default keyboard shortcut pre-defined to launch
a terminal now that its not available via the right-click.  The
shortcut hook is there, but is undefined by default.

> 
> This is the sort of 'brave' move that reminds me (at a much smaller
> scale, I agree) to the spatial nautilus business. I haven't met a single
> person that wasn't upset by that change. And that was shoved down
> people's throats rather unceremoniously.

There will always be a group of people who are irrationally vocal
about any change. I wasn't upset by the change. In fact I've made an
effort to track my usage of spatial nautilus versus browser nautilus.
I set up one system each way.  Over a period of weeks I found I was
using  spatial nautilus far more than I use browser nautilus. On the
browser nautilus system I was still doing nearly all of my file system
operations via a terminal.  On the system with spatial nautilus i
actually started using nautilus more.  I'd love to be upset and shake
my fist at the change, but my usage patterns did actually change with
the introduction of spatial.

-jef"has no natural depth-perception"spaleta



From dimi at lattica.com  Tue Jul 12 05:14:20 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 12 Jul 2005 01:14:20 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121143246.10435.9.camel@cutter>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>  <1121143246.10435.9.camel@cutter>
Message-ID: <1121145260.11210.41.camel@dimi>

On Tue, 2005-07-12 at 00:40 -0400, seth vidal wrote:
> My name is seth vidal. I was not upset by spatial nautilus.

Glad to hear that. But this is missing the point -- forcing such
preferences onto others is not right, and the people that don't like
this behavior (and let me tell you, in my experience they are the vast
majority, with the minority being ambivalent, no real fans AFAIK)
are going to be rightfully upset. But I digress, if folks didn't figure
it by now that this is not the way to make friends...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From bclark at redhat.com  Tue Jul 12 05:10:40 2005
From: bclark at redhat.com (Bryan Clark)
Date: Tue, 12 Jul 2005 01:10:40 -0400
Subject: No more right click terminal
In-Reply-To: <1121143049.3521.16.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
Message-ID: <1121145040.2685.16.camel@rhbw.boston.redhat.com>

Seriously dude if you calm down for just a little while, allowing for
someone to respond who actually knows what happened we won't have a
witch trial on our hands. ;-)

It's obviously not perfect yet, but GNOME is making progress to being
both Power Tool friendly (read you) and regular person friendly (read
hopefully everyone else).

This page describes lots of cool things you can install and use to trick
out your GNOME DE as you might like.
http://live.gnome.org/PowerUserTools

More specifically this page has the package for the _new_ open terminal
menu item that actually works better in most ways than the old one.
http://manny.cluecoder.org/packages/nautilus-open-terminal/

This new project gives you the option to open a terminal in any nautilus
window instead of just on the desktop.  The desktop menu will open a
terminal just like it did before.  However when you open a terminal from
nautilus window showing "~/folder-x/folder-y/" your terminal will be
opened to the same directory.  This is something new that I think makes
this option even better.

Now the new item isn't at the top of the context menu, but I think
that's the only real downside to this projects effort so far.

It'd be great if someone packaged this project in extras so that crew
with torches and pitch forks out front of my place will go home.

Cheers,
~ Bryan

On Mon, 2005-07-11 at 21:37 -0700, Jesse Keating wrote:
> I would really like to open this up to the discussion for the users and
> developers of Fedora.  This feature is very ingrained in a lot of our
> muscle memories, deeply embedded in our internal and external
> documentation for not just end users but entry level admins, group
> admins, and a myriad of folks that really do have a use for the
> terminal.  Sure you can just as easily get to it by selecting it from a
> menu, so that actually goes in my favor.  If we're trying to 'protect'
> the user, why have it in the menu at all?  If the end user that Gnome
> seems to care about won't notice, why not leave it so that the people
> who have a clue and have the capability of helping out don't get pissed
> off by yet another 'lets break history in favor of some "usability" we
> think is right for the fabled holy grail of an end user'.
> 
> This is yet another move in a long history of Gnome moves that makes me
> wish somebody forked gnome a while ago and removed all these stupid
> 'save the end user from themselves' changes.  For god sakes, make a 'end
> user safe' UI that has all these things in it, and then make a 'real
> user' UI that actually allows work to be done in the way that it has
> been done for years.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list



From skvidal at phy.duke.edu  Tue Jul 12 05:25:04 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 12 Jul 2005 01:25:04 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121145260.11210.41.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>  <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi>
Message-ID: <1121145904.10435.19.camel@cutter>

On Tue, 2005-07-12 at 01:14 -0400, Dimi Paun wrote:
> 
> Glad to hear that. But this is missing the point -- forcing such
> preferences onto others is not right, and the people that don't like
> this behavior (and let me tell you, in my experience they are the vast
> majority, with the minority being ambivalent, no real fans AFAIK)
> are going to be rightfully upset. But I digress, if folks didn't figure
> it by now that this is not the way to make friends...

1. I think you're confusing vocal contingent on /. and osnews with
'majority'
2. it's not about forcing preferences it is about making sure the code
is maintainable and not riddled with exceptions for corner cases and
optional menus and ridiculous configuration dialogs.

If you really want to learn more about how these decisions get made and
maybe help with them then go be involved in gnome development. But
complaining on fedora-devel-list isn't going to help.

-sv




From jkeating at j2solutions.net  Tue Jul 12 05:31:40 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 11 Jul 2005 22:31:40 -0700
Subject: No more right click terminal
In-Reply-To: <1121145040.2685.16.camel@rhbw.boston.redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121145040.2685.16.camel@rhbw.boston.redhat.com>
Message-ID: <1121146300.3521.27.camel@localhost.localdomain>

On Tue, 2005-07-12 at 01:10 -0400, Bryan Clark wrote:
> Seriously dude if you calm down for just a little while, allowing for
> someone to respond who actually knows what happened we won't have a
> witch trial on our hands. ;-)

/me takes the crack pipe out of his hands and puts it away for the
night.  Ok, moving on.

> It's obviously not perfect yet, but GNOME is making progress to being
> both Power Tool friendly (read you) and regular person friendly (read
> hopefully everyone else).

I'm very happy to hear that us relegated power users are still being
thought of when Gnome moves forward.  That does actually have a calming
effect.

> This page describes lots of cool things you can install and use to trick
> out your GNOME DE as you might like.
> http://live.gnome.org/PowerUserTools

I had no idea this existed!  Thank you very much!

> More specifically this page has the package for the _new_ open terminal
> menu item that actually works better in most ways than the old one.
> http://manny.cluecoder.org/packages/nautilus-open-terminal/

Hrm, possibly useful, maybe.  Now, if there was perhaps a menu option
for 'open file in terminal w/ vim' perhaps I'd like it (:  But
graphically clicking a bunch of spacial icons to get to a directory
where I might want to do some terminal level file management isn't as
efficient as popping open a terminal and cding directly to where I know
I'm going, or just calling something from ~.  A good chunk of what I use
the terminal for, I do it w/out leaving ~, or it is something indepth
like editing code and checking in/out of svn, or sshing out to some
other system to do something.  Can't very well spacial browse to another
host....

> This new project gives you the option to open a terminal in any nautilus
> window instead of just on the desktop.  The desktop menu will open a
> terminal just like it did before.  However when you open a terminal from
> nautilus window showing "~/folder-x/folder-y/" your terminal will be
> opened to the same directory.  This is something new that I think makes
> this option even better.

By "Desktop Menu" do you mean right-click, or do you mean the main menu
thing then system tools, and finally terminal?

> Now the new item isn't at the top of the context menu, but I think
> that's the only real downside to this projects effort so far.
> 
> It'd be great if someone packaged this project in extras so that crew
> with torches and pitch forks out front of my place will go home.

Just out of idle curiosity (or maybe not so idle) how many lines of code
is it really to add one more item to the default desktop right click
context menu?  Is it not something that can be modified or extended on a
live system w/out a complete gnome or nautilus recompile?  Which system
is it that drives the context menu? Gnome or Nautilus or Metacity
or.... ?

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/20699f5b/attachment.sig>

From bclark at redhat.com  Tue Jul 12 05:49:40 2005
From: bclark at redhat.com (Bryan Clark)
Date: Tue, 12 Jul 2005 01:49:40 -0400
Subject: No more right click terminal
In-Reply-To: <1121146300.3521.27.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121145040.2685.16.camel@rhbw.boston.redhat.com>
	<1121146300.3521.27.camel@localhost.localdomain>
Message-ID: <1121147380.2685.24.camel@rhbw.boston.redhat.com>

On Mon, 2005-07-11 at 22:31 -0700, Jesse Keating wrote:
> > This new project gives you the option to open a terminal in any nautilus
> > window instead of just on the desktop.  The desktop menu will open a
> > terminal just like it did before.  However when you open a terminal from
> > nautilus window showing "~/folder-x/folder-y/" your terminal will be
> > opened to the same directory.  This is something new that I think makes
> > this option even better.
> 
> By "Desktop Menu" do you mean right-click, or do you mean the main menu
> thing then system tools, and finally terminal?

Yes, go ahead and try it out.

> Just out of idle curiosity (or maybe not so idle) how many lines of code
> is it really to add one more item to the default desktop right click
> context menu?  Is it not something that can be modified or extended on a
> live system w/out a complete gnome or nautilus recompile?  Which system
> is it that drives the context menu? Gnome or Nautilus or Metacity
> or.... ?

AFAIK it's nautilus that drives this, the beauty and perhaps the danger
of this is that you could open up any thing you wanted from something
like this.   

A lot of this is boiler-plate code, there really isn't too much to this.
And there are python bindings to do all this too, however I don't know
if we package those either.

[clarkbw at rhbw src]$ wc *.c *.h
  314   737  8064 nautilus-open-terminal.c
   58   206  1583 open-terminal.c
   55   223  1853 nautilus-open-terminal.h
  427  1166 11500 total

Cheers,
~ Bryan



From koneko.em at gmail.com  Tue Jul 12 05:55:22 2005
From: koneko.em at gmail.com (Emily Brantley)
Date: Tue, 12 Jul 2005 01:55:22 -0400
Subject: No more right click terminal
In-Reply-To: <1121146300.3521.27.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121145040.2685.16.camel@rhbw.boston.redhat.com>
	<1121146300.3521.27.camel@localhost.localdomain>
Message-ID: <42D35B4A.9030507@gmail.com>

> Just out of idle curiosity (or maybe not so idle) how many lines of code
> is it really to add one more item to the default desktop right click
> context menu?  Is it not something that can be modified or extended on a
> live system w/out a complete gnome or nautilus recompile?  Which system
> is it that drives the context menu? Gnome or Nautilus or Metacity
> or.... ?
> 
> 

don't forget about nautilus-scripts.  they still exist, and they still work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/1f757973/attachment.sig>

From jkeating at j2solutions.net  Tue Jul 12 06:07:35 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 11 Jul 2005 23:07:35 -0700
Subject: No more right click terminal
In-Reply-To: <1121147380.2685.24.camel@rhbw.boston.redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121145040.2685.16.camel@rhbw.boston.redhat.com>
	<1121146300.3521.27.camel@localhost.localdomain>
	<1121147380.2685.24.camel@rhbw.boston.redhat.com>
Message-ID: <1121148456.3521.29.camel@localhost.localdomain>

On Tue, 2005-07-12 at 01:49 -0400, Bryan Clark wrote:
> AFAIK it's nautilus that drives this, the beauty and perhaps the
> danger
> of this is that you could open up any thing you wanted from something
> like this.   
> 
> A lot of this is boiler-plate code, there really isn't too much to
> this.
> And there are python bindings to do all this too, however I don't know
> if we package those either.
> 
> [clarkbw at rhbw src]$ wc *.c *.h
>   314   737  8064 nautilus-open-terminal.c
>    58   206  1583 open-terminal.c
>    55   223  1853 nautilus-open-terminal.h
>   427  1166 11500 total

Hrm, I meant the code that drives what options are visible when I right
click the desktop.  I see an itch that people may want scratched with a
small package that just adds the terminal option back to the right click
menu.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050711/b912ca1d/attachment.sig>

From arjanv at redhat.com  Tue Jul 12 06:12:39 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 12 Jul 2005 08:12:39 +0200
Subject: nptl configuration
In-Reply-To: <53d4ffb8050711185956148c2c@mail.gmail.com>
References: <1120914536.7035.0.camel@localhost.localdomain>
	<53d4ffb8050711185956148c2c@mail.gmail.com>
Message-ID: <1121148760.3171.8.camel@laptopd505.fenrus.org>

On Tue, 2005-07-12 at 07:29 +0530, Jatin Nansi wrote:
> on all recent fedora distros, /lib/libc.so.6 is the old linux threads
> implementation - maintained for backward compatibility purposes. 

this isn't the case in fc4 anymore; there /lib/libc.so.6 is the nptl
glibc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/d66eb3e1/attachment.sig>

From divij at innomedia.soft.net  Tue Jul 12 07:00:39 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Tue, 12 Jul 2005 12:30:39 +0530
Subject: nptl and signals
Message-ID: <1121151639.8255.32.camel@localhost.localdomain>


-------------- next part --------------
An embedded message was scrubbed...
From: divij bhatt <divij at innomedia.soft.net>
Subject: [nptl] nptl and signals
Date: Tue, 12 Jul 2005 12:24:30 +0530
Size: 9184
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/cba36880/attachment.eml>

From divij at innomedia.soft.net  Tue Jul 12 07:05:20 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Tue, 12 Jul 2005 12:35:20 +0530
Subject: nptl and signals
Message-ID: <1121151920.8255.35.camel@localhost.localdomain>

Hi,
   I have problem regarding nptl in multi-threading environment.I am
creating three threads and each thread is calling a functions in which I
am setting the time for each thread using setitimer.On expiration of
that timer SIGALRM is called which calls a signal handler function in
which I am setting the flag and when control return to the main program
I am checking that flag if it is one then I am sending the packet and
again make that flag 0.I am using thread specific data and use set
specific and getspecific to read the threads data.
But the problem is that in signal handler instead of 3 there are 4
threads running(4th one suppose to be main thread) which disturbs the
timing of other threads.Which results in to the packet drooping.Also the
control is not returning to the main program So kindly help me out,I am
also attaching the copy of source code.

Thanks in Advance
Divij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nptl.c
Type: text/x-csrc
Size: 5669 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/1c07c0f5/attachment.bin>

From divij at innomedia.soft.net  Tue Jul 12 08:11:06 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Tue, 12 Jul 2005 13:41:06 +0530
Subject: glibc
Message-ID: <1121155866.8669.2.camel@localhost.localdomain>

Hi,
    How would i know that my glibc is nptl enabled.


Thanks In Advance
Divij



From jakub at redhat.com  Tue Jul 12 08:11:47 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 12 Jul 2005 04:11:47 -0400
Subject: glibc
In-Reply-To: <1121155866.8669.2.camel@localhost.localdomain>
References: <1121155866.8669.2.camel@localhost.localdomain>
Message-ID: <20050712081147.GP4884@devserv.devel.redhat.com>

On Tue, Jul 12, 2005 at 01:41:06PM +0530, divij bhatt wrote:
> Hi,
>     How would i know that my glibc is nptl enabled.

getconf GNU_LIBPTHREAD_VERSION

	Jakub



From arjanv at redhat.com  Tue Jul 12 08:17:06 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 12 Jul 2005 10:17:06 +0200
Subject: glibc
In-Reply-To: <1121155866.8669.2.camel@localhost.localdomain>
References: <1121155866.8669.2.camel@localhost.localdomain>
Message-ID: <1121156226.3171.12.camel@laptopd505.fenrus.org>

On Tue, 2005-07-12 at 13:41 +0530, divij bhatt wrote:
> Hi,
>     How would i know that my glibc is nptl enabled.

all fedora releases have a nptl enabled glibc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/df3f17d9/attachment.sig>

From rc040203 at freenet.de  Tue Jul 12 08:26:56 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 12 Jul 2005 10:26:56 +0200
Subject: glibc
In-Reply-To: <20050712081147.GP4884@devserv.devel.redhat.com>
References: <1121155866.8669.2.camel@localhost.localdomain>
	<20050712081147.GP4884@devserv.devel.redhat.com>
Message-ID: <1121156816.10841.44.camel@mccallum.corsepiu.local>

On Tue, 2005-07-12 at 04:11 -0400, Jakub Jelinek wrote:
> On Tue, Jul 12, 2005 at 01:41:06PM +0530, divij bhatt wrote:
> > Hi,
> >     How would i know that my glibc is nptl enabled.
> 
> getconf GNU_LIBPTHREAD_VERSION

How about cross-building? 
Any preprocessor define or symbol from glibc to check for by
autoconf-magic?

Ralf




From arjanv at redhat.com  Tue Jul 12 08:36:29 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 12 Jul 2005 10:36:29 +0200
Subject: glibc
In-Reply-To: <1121156816.10841.44.camel@mccallum.corsepiu.local>
References: <1121155866.8669.2.camel@localhost.localdomain>
	<20050712081147.GP4884@devserv.devel.redhat.com>
	<1121156816.10841.44.camel@mccallum.corsepiu.local>
Message-ID: <1121157390.3171.16.camel@laptopd505.fenrus.org>

On Tue, 2005-07-12 at 10:26 +0200, Ralf Corsepius wrote:
> On Tue, 2005-07-12 at 04:11 -0400, Jakub Jelinek wrote:
> > On Tue, Jul 12, 2005 at 01:41:06PM +0530, divij bhatt wrote:
> > > Hi,
> > >     How would i know that my glibc is nptl enabled.
> > 
> > getconf GNU_LIBPTHREAD_VERSION
> 
> How about cross-building? 
> Any preprocessor define or symbol from glibc to check for by
> autoconf-magic?

why?
If your program code cares I think you're doing something wrong :)
(especially since you could well end up building against linuxthreads
but running against nptl, as fedora core 3 and prior did)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/82131ec2/attachment.sig>

From rc040203 at freenet.de  Tue Jul 12 09:07:29 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 12 Jul 2005 11:07:29 +0200
Subject: glibc
In-Reply-To: <1121157390.3171.16.camel@laptopd505.fenrus.org>
References: <1121155866.8669.2.camel@localhost.localdomain>
	<20050712081147.GP4884@devserv.devel.redhat.com>
	<1121156816.10841.44.camel@mccallum.corsepiu.local>
	<1121157390.3171.16.camel@laptopd505.fenrus.org>
Message-ID: <1121159249.10841.51.camel@mccallum.corsepiu.local>

On Tue, 2005-07-12 at 10:36 +0200, Arjan van de Ven wrote:
> On Tue, 2005-07-12 at 10:26 +0200, Ralf Corsepius wrote:
> > On Tue, 2005-07-12 at 04:11 -0400, Jakub Jelinek wrote:
> > > On Tue, Jul 12, 2005 at 01:41:06PM +0530, divij bhatt wrote:
> > > > Hi,
> > > >     How would i know that my glibc is nptl enabled.
> > > 
> > > getconf GNU_LIBPTHREAD_VERSION
> > 
> > How about cross-building? 
> > Any preprocessor define or symbol from glibc to check for by
> > autoconf-magic?
> 
> why?
> If your program code cares I think you're doing something wrong :)
Agreed, but ...

> (especially since you could well end up building against linuxthreads
> but running against nptl, as fedora core 3 and prior did)

... did you ever try to write a portable pthreaded program?

I did, and found myself in a forest of wildest autoconf checks, because
the pthread API and pthread run-time behaving varies quite largely
between OSes and pthread implementations. Now, I am wondering what might
have changed on Linux and which pitfalls might have been introduced ...

Ralf




From camilo at mesias.co.uk  Tue Jul 12 10:39:21 2005
From: camilo at mesias.co.uk (Cam)
Date: Tue, 12 Jul 2005 11:39:21 +0100
Subject: No more right click terminal
In-Reply-To: <1121143049.3521.16.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
Message-ID: <42D39DD9.8070106@mesias.co.uk>

Jesse

> I would really like to open this up to the discussion for the users and
> developers of Fedora.  This feature is very ingrained in a lot of our
> muscle memories, deeply embedded in our internal and external
> documentation for not just end users but entry level admins, group
> admins, and a myriad of folks that really do have a use for the
> terminal.

I used that desktop menu, but I will now try to configure ctrl-shift-T 
to open a new terminal. It's the same key sequence to open a new tab in 
a terminal... Hope that can be made to work.

It would be nice to have a sensible default for this, it would help 
power users that move to another desktop temporarily.

-Cam

-- 
camilo at mesias.co.uk                                                 <--



From buildsys at redhat.com  Tue Jul 12 11:09:13 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 12 Jul 2005 07:09:13 -0400
Subject: rawhide report: 20050712 changes
Message-ID: <200507121109.j6CB9Dmo001524@porkchop.devel.redhat.com>

 

 
Updated Packages:

alsa-utils-1.0.9rf-3
--------------------
* Mon Jul 11 2005 Martin Stransky <stransky at redhat.com> 1.0.9-3
- New alsaunmute utility
- Add autoconf to BuildRequires (#162483)

epiphany-1.7.2-1
----------------
* Mon Jul 11 2005 Christopher Aillon <caillon at redhat.com> - 1.7.2-1
- Update to 1.7.2

file-roller-2.11.2-1
--------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.2-1
- New upstream version

gaim-1:1.4.0-4.fc5
------------------
* Mon Jul 11 2005 Warren Togami <wtogami at redhat.com> 1:1.4.0-4
- 149: MSN username with space disconnect fix
- Do not own perl dir, remove empty files (#162994 jpo)

* Sun Jul 10 2005 Warren Togami <wtogami at redhat.com> 1:1.4.0-2
- 148: AIM login crash fix

gnome-menus-2.11.1.1-2
----------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.1.1-2
- Undo the split into tiny subpackages, instead move
  the Python bindings and the editor into the main package.
- Fix dependencies

gnome-terminal-2.11.1-1
-----------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.1-1
-Newer upstream version

libgnome-2.11.1-1
-----------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.1-1
- Newer upstream version

* Wed Apr 13 2005 John (J5) Palmieri <johnp at redhat.com> - 2.10.0-3
- Change the default icon theme back to Clearlooks as the Clearlooks
  icon theme will now inherit from Bluecurve

* Wed Apr 13 2005 John (J5) Palmieri <johnp at redhat.com> - 2.10.0-2
- Reenable the default icon theme patch to be bluecurve

libgnomeprint22-2.11.0-1
------------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.0-1
- Newer upstream version

libgnomeui-2.11.1-1
-------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.1-1
- Newer upstream version

libwnck-2.11.4-1
----------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.4-1
- New upstream version

nautilus-cd-burner-2.11.4-1
---------------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.4-1
- Newer upstream version
- Link against libstdc++. The hack doesn't really work

* Wed Apr 13 2005 David Zeuthen <davidz at redhat.com> - 2.10.0-3
- Fix Requires for -devel package (#152505)

procps-3.2.5-6.3
----------------
* Mon Jul 11 2005 Karel Zak <kzak at redhat.com> 3.2.5-6.3
- imporoved procps-3.2.5-sysctl-writeonly.patch

* Fri Jul 08 2005 Karel Zak <kzak at redhat.com> 3.2.5-6.2
- fix #161449 - "top" ignores user and system toprc
- fix #161559 - top segfaults when resizing konsole
- fix #160796 - vmstat crashes when accessing LVM partition.

selinux-policy-strict-1.25.1-8
------------------------------
* Fri Jul 08 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-8
- Fix saslauthd policy to allow imapd and shadow.

sysfsutils-1.3.0-1
------------------
* Fri Jul 08 2005 Bill Nottingham  <notting at redhat.com> 1.3.0-1
- update to 1.3.0

system-config-securitylevel-1.5.11-1
------------------------------------
* Mon Jul 11 2005 Dan Walsh <dwalsh at redhat.com> 1.5.11-1
- Add additional booleans

* Sat Jun 18 2005 Dan Walsh <dwalsh at redhat.com> 1.5.10-1
- Add additional booleans

system-config-soundcard-1.2.12-3
--------------------------------
* Mon Jul 11 2005 Martin Stransky <stransky at redhat.com> 1.2.12-3
- using /usr/bin/alsaunmute for unmuting cards

* Mon Jun 20 2005 Martin Stransky <stransky at redhat.com> 1.2.12-2
- read cards mumbers from /proc/asound/modules

vino-2.11.1.2-1
---------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> 2.11.1.2-1
- Newer upstream version
- Drop upstreamed patches

vixie-cron-4:4.1-36.FC5
-----------------------
* Mon Jul 11 2005 Jason Vas Dias <jvdias at redhat.com> - 4.1-36.FC4
- fix bug 162887: allow multiple /etc/cron.d crontabs for *system* user
- further fix for bug 154920 / CAN-2005-1038 ( crontab -e ):
     invoke editor and copy operation as non-root user

* Fri Jun 17 2005 Jason Vas Dias <jvdias at redhat.com> - 4.1-FC4.34
- fix bug 160811: FC3 version compared >= FC4 version
- fix bug 159216: add pam_loginuid support for new audit system

* Thu Apr 14 2005 Jason Vas Dias <jvdias at redhat.com> - 4.1-33_FC4
- fix bug 154922 / CAN-2005-1038: check that new crontab is 
      regular file after editor session ends.
- fix bug 154575: use PATH_MAX (4096) as max filename length; also make 
      limits on command line and env.var. lengths sensible (131072).

wget-1.10-4
-----------
* Mon Jul 11 2005 Karsten Hopp <karsten at redhat.de> 1.10-4
- update german translation (Robert Scheck)

Broken deps for i386
----------------------------------------------------------
	gnome-applets - 1:2.11.1-1.i386 requires libwnck-1.so.16
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	usermode-gtk - 1.80-1.i386 requires libwnck-1.so.16
	sound-juicer - 2.10.1-1.i386 requires libnautilus-burn.so.1
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-panel - 2.11.4-1.i386 requires libwnck-1.so.16
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnome-system-monitor - 2.10.0-2.i386 requires libwnck-1.so.16
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-media - 2.10.2-4.i386 requires libnautilus-burn.so.1
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dasher - 3.2.15-1.i386 requires libwnck-1.so.16
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gok - 1.0.5-1.i386 requires libwnck-1.so.16
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-system-monitor - 2.10.0-2.s390 requires libwnck-1.so.16
	gok - 1.0.5-1.s390 requires libwnck-1.so.16
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390 requires gjdoc
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	usermode-gtk - 1.80-1.s390 requires libwnck-1.so.16
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	selinux-policy-strict - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	dhcp - 10:3.0.2-14.FC5.s390 requires kernel >= 0:2.2.18
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	gnome-applets - 1:2.11.1-1.s390 requires libwnck-1.so.16
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	gnome-panel - 2.11.4-1.s390 requires libwnck-1.so.16
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	dasher - 3.2.15-1.s390 requires libwnck-1.so.16



Broken deps for ia64
----------------------------------------------------------
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-applets - 1:2.11.1-1.ia64 requires libwnck-1.so.16()(64bit)
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	gnome-panel - 2.11.4-1.ia64 requires libwnck-1.so.16()(64bit)
	dasher - 3.2.15-1.ia64 requires libwnck-1.so.16()(64bit)
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	gnome-media - 2.10.2-4.ia64 requires libnautilus-burn.so.1()(64bit)
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	gok - 1.0.5-1.ia64 requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-system-monitor - 2.10.0-2.ia64 requires libwnck-1.so.16()(64bit)
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	usermode-gtk - 1.80-1.ia64 requires libwnck-1.so.16()(64bit)
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	sound-juicer - 2.10.1-1.ia64 requires libnautilus-burn.so.1()(64bit)
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ia64 requires gjdoc
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5



Broken deps for ppc
----------------------------------------------------------
	gnome-applets - 1:2.11.1-1.ppc requires libwnck-1.so.16
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gok - 1.0.5-1.ppc requires libwnck-1.so.16
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	usermode-gtk - 1.80-1.ppc requires libwnck-1.so.16
	dasher - 3.2.15-1.ppc requires libwnck-1.so.16
	gnome-media - 2.10.2-4.ppc requires libnautilus-burn.so.1
	gnome-panel - 2.11.4-1.ppc requires libwnck-1.so.16
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-system-monitor - 2.10.0-2.ppc requires libwnck-1.so.16
	sound-juicer - 2.10.1-1.ppc requires libnautilus-burn.so.1
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1



Broken deps for s390x
----------------------------------------------------------
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390x requires gjdoc
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	usermode-gtk - 1.80-1.s390x requires libwnck-1.so.16()(64bit)
	hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	dasher - 3.2.15-1.s390x requires libwnck-1.so.16()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	selinux-policy-strict-sources - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	selinux-policy-targeted - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	selinux-policy-strict - 1.25.1-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-panel - 2.11.4-1.s390x requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	gnome-system-monitor - 2.10.0-2.s390x requires libwnck-1.so.16()(64bit)
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	gok - 1.0.5-1.s390x requires libwnck-1.so.16()(64bit)
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	dhcp - 10:3.0.2-14.FC5.s390x requires kernel >= 0:2.2.18
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	gnome-applets - 1:2.11.1-1.s390x requires libwnck-1.so.16()(64bit)
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1



Broken deps for x86_64
----------------------------------------------------------
	sound-juicer - 2.10.1-1.x86_64 requires libnautilus-burn.so.1()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-applets - 1:2.11.1-1.x86_64 requires libwnck-1.so.16()(64bit)
	dasher - 3.2.15-1.x86_64 requires libwnck-1.so.16()(64bit)
	usermode-gtk - 1.80-1.x86_64 requires libwnck-1.so.16()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gok - 1.0.5-1.x86_64 requires libwnck-1.so.16()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-panel - 2.11.4-1.x86_64 requires libwnck-1.so.16()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-media - 2.10.2-4.x86_64 requires libnautilus-burn.so.1()(64bit)
	gnome-system-monitor - 2.10.0-2.x86_64 requires libwnck-1.so.16()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	gnome-media - 2.10.2-4.ppc64 requires libnautilus-burn.so.1()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	firstboot - 1.3.43-1.noarch requires system-config-display
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	dasher - 3.2.15-1.ppc64 requires libwnck-1.so.16()(64bit)
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	sound-juicer - 2.10.1-1.ppc64 requires libnautilus-burn.so.1()(64bit)
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ppc64 requires gjdoc
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	gnome-applets - 1:2.11.1-1.ppc64 requires libwnck-1.so.16()(64bit)
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	usermode-gtk - 1.80-1.ppc64 requires libwnck-1.so.16()(64bit)
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	gnome-system-monitor - 2.10.0-2.ppc64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	gnome-panel - 2.11.4-1.ppc64 requires libwnck-1.so.16()(64bit)
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gok - 1.0.5-1.ppc64 requires libwnck-1.so.16()(64bit)
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp





From mbneto at gmail.com  Tue Jul 12 11:27:51 2005
From: mbneto at gmail.com (mbneto)
Date: Tue, 12 Jul 2005 07:27:51 -0400
Subject: New eclipse
Message-ID: <5cf776b805071204274df1a03c@mail.gmail.com>

Hi,

the 3.1 eclipse was released a few days ago and I was wondering when
will it be available in rawhide and FC4.

tks.



From dimi at lattica.com  Tue Jul 12 12:37:27 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 12 Jul 2005 08:37:27 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121145904.10435.19.camel@cutter>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>  <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi>  <1121145904.10435.19.camel@cutter>
Message-ID: <1121171847.11210.54.camel@dimi>

On Tue, 2005-07-12 at 01:25 -0400, seth vidal wrote:
> 1. I think you're confusing vocal contingent on /. and osnews with
> 'majority'

I am not. I am judging from my first hand experience: mine, and the
folks that I know. I know, my experience is totally irrelevant, as is
the opinion of many users on /. or osnews. But there's little point in
arguing this, if you think the way this sort of change was made is cool,
let's just agree to disagree.

> 2. it's not about forcing preferences it is about making sure the code
> is maintainable and not riddled with exceptions for corner cases and
> optional menus and ridiculous configuration dialogs.

This is such a geeky argument... People are complaining about a menu
removal, and somehow we're talking about code maintainability. Maybe
this sort of argument works on newbies, but please! I've been in the
business all my life to know that:
  1. One has nothing to do with the other. If having the menu there is
part of the requirements, you code accordingly.
  2. If having _one_ menu there screws up the code beyond repair,
removing it will not help you any since the folks writing it have no
clue to begin with.

And shutting people up every time they complain that this is
fedora-devel, and not some upstream list is also bad policy IMO: at the
end of the day, people use Fedora Core, and they'll judge the overall
result, with little thought of where bad decisions come from. This is a
good forum to discuss these problems, if not we might as well close down
the list.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mitr at volny.cz  Tue Jul 12 12:41:15 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Tue, 12 Jul 2005 14:41:15 +0200
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121171847.11210.54.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi> <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi> <1121145904.10435.19.camel@cutter>
	<1121171847.11210.54.camel@dimi>
Message-ID: <20050712124110.GC9789@chrys.ms.mff.cuni.cz>

On Tue, Jul 12, 2005 at 08:37:27AM -0400, Dimi Paun wrote:
> And shutting people up every time they complain that this is
> fedora-devel, and not some upstream list is also bad policy IMO: at the
> end of the day, people use Fedora Core, and they'll judge the overall
> result, with little thought of where bad decisions come from. This is a
> good forum to discuss these problems,
fedora-devel-list is IMHO not the right place to discuss problems without
even planing to discuss fixing them too.
	Mirek



From sundaram at redhat.com  Tue Jul 12 12:44:11 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 12 Jul 2005 18:14:11 +0530
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121171847.11210.54.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>	<1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>	<1121139573.11210.19.camel@dimi>	<604aa79105071121247b3616b7@mail.gmail.com>	<1121142896.11210.36.camel@dimi>
	<1121143246.10435.9.camel@cutter>	<1121145260.11210.41.camel@dimi>
	<1121145904.10435.19.camel@cutter> <1121171847.11210.54.camel@dimi>
Message-ID: <42D3BB1B.6050503@redhat.com>

Hi

>And shutting people up every time they complain that this is
>fedora-devel, and not some upstream list is also bad policy IMO
>
Fedora pretty much picks up upstream changes all the time.  Removing the 
terminal option  from the context menu was a deliberate decision.  You 
have already heard the rationale behind that decision. You might not 
agree with that but Fedora is not going to override it now. So if you 
have complaints you should take it upstream. Thats the right forum and 
thats how it works.

regards
Rahul



From dimi at lattica.com  Tue Jul 12 12:44:46 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 12 Jul 2005 08:44:46 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <20050712124110.GC9789@chrys.ms.mff.cuni.cz>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi> <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi> <1121145904.10435.19.camel@cutter>
	<1121171847.11210.54.camel@dimi>
	<20050712124110.GC9789@chrys.ms.mff.cuni.cz>
Message-ID: <1121172286.11210.57.camel@dimi>

On Tue, 2005-07-12 at 14:41 +0200, Miloslav Trmac wrote:
> fedora-devel-list is IMHO not the right place to discuss problems
> without even planing to discuss fixing them too.

The menu thing is 100% political, the fix is probably 2-3 lines of code.
We just need a decision, I'm just not happy with the new direction :) If
we decide to re-add it, I sure the patch can be produced shortly.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From skvidal at phy.duke.edu  Tue Jul 12 12:54:14 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 12 Jul 2005 08:54:14 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121171847.11210.54.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose> <1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>  <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi>  <1121145904.10435.19.camel@cutter>
	<1121171847.11210.54.camel@dimi>
Message-ID: <1121172854.12742.2.camel@cutter>


> And shutting people up every time they complain that this is
> fedora-devel, and not some upstream list is also bad policy IMO: at the
> end of the day, people use Fedora Core, and they'll judge the overall
> result, with little thought of where bad decisions come from. This is a
> good forum to discuss these problems, if not we might as well close down
> the list.

At the end of the day fedora follows the decisions of upstream and
shouldn't be patching in items like a gnome-terminal on the desktop root
right-click menu.

-sv




From richardl at redhat.com  Tue Jul 12 12:55:15 2005
From: richardl at redhat.com (Richard Li)
Date: Tue, 12 Jul 2005 08:55:15 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121172854.12742.2.camel@cutter>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>	<1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>	<1121139573.11210.19.camel@dimi>	<604aa79105071121247b3616b7@mail.gmail.com>	<1121142896.11210.36.camel@dimi>
	<1121143246.10435.9.camel@cutter>	<1121145260.11210.41.camel@dimi>
	<1121145904.10435.19.camel@cutter>	<1121171847.11210.54.camel@dimi>
	<1121172854.12742.2.camel@cutter>
Message-ID: <42D3BDB3.90604@redhat.com>

seth vidal wrote:

>>And shutting people up every time they complain that this is
>>fedora-devel, and not some upstream list is also bad policy IMO: at the
>>end of the day, people use Fedora Core, and they'll judge the overall
>>result, with little thought of where bad decisions come from. This is a
>>good forum to discuss these problems, if not we might as well close down
>>the list.
>>    
>>
>
>At the end of the day fedora follows the decisions of upstream and
>shouldn't be patching in items like a gnome-terminal on the desktop root
>right-click menu.
>  
>
And before you ask we don't want to deviate from upstream because that 
creates forking and therein lies the unsustainable, unmaintainable way 
of badness. That's why you get the answer of "upstream". Yes sometimes 
we carry patches but 99.9% time (I hope) it's because upstream hasn't 
merged the patch but it has been agreed to in principle.



From guhvies at gmail.com  Tue Jul 12 12:56:23 2005
From: guhvies at gmail.com (ne...)
Date: Tue, 12 Jul 2005 08:56:23 -0400
Subject: New eclipse
In-Reply-To: <5cf776b805071204274df1a03c@mail.gmail.com>
References: <5cf776b805071204274df1a03c@mail.gmail.com>
Message-ID: <a227b70c050712055624cfc3fd@mail.gmail.com>

On 7/12/05, mbneto <mbneto at gmail.com> wrote:
> Hi,
> 
> the 3.1 eclipse was released a few days ago and I was wondering when
> will it be available in rawhide and FC4.
rawhide report: 20050705 changes shows eclipse 3.1.0.

N.Emile...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard. 
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From vonbrand at inf.utfsm.cl  Tue Jul 12 13:34:51 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Tue, 12 Jul 2005 09:34:51 -0400
Subject: rawhide report: 20050711 changes 
In-Reply-To: Your message of "Tue, 12 Jul 2005 00:24:09 -0400."
	<604aa79105071121247b3616b7@mail.gmail.com> 
Message-ID: <200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>

Jeff Spaleta <jspaleta at gmail.com> wrote:
> On 7/11/05, Dimi Paun <dimi at lattica.com> wrote:
> > Why? Out of the entire GNOME menu, that was the most useful feature
> > by an order of magnitude (for me).

> (for you)  sums it up.  Perhaps... just perhaps... you aren't inside
> the target audience that Gnome is designing for. [...]

[...]

>   Its pretty brave of Gnome to actually say mainstream users of their
> desktop do not need quick access to a terminal to get typical
> workloads done... but I can't disagree with the goal. Mainstream
> office and home users of a modern computer desktop environment should
> not need to use the terminal so oftern that the terminal should be in
> the main desktop menu.

Right. And changing the desktop background is a regular operation,
/absolutely requiring/ an entry there.

Oh, come on. Sure, GUIs /can/ be used in a just-point&drool way, but the
commands are what makes *ix powerful.

[Yes, for me X is just an easy way to have half a dozen ttys open together
 with xemacs.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From vonbrand at inf.utfsm.cl  Tue Jul 12 13:36:22 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Tue, 12 Jul 2005 09:36:22 -0400
Subject: rawhide report: 20050711 changes 
In-Reply-To: Your message of "Tue, 12 Jul 2005 00:40:46 -0400."
	<1121143246.10435.9.camel@cutter> 
Message-ID: <200507121336.j6CDaM22006008@laptop11.inf.utfsm.cl>

seth vidal <skvidal at phy.duke.edu> wrote:
> On Tue, 2005-07-12 at 00:34 -0400, Dimi Paun wrote:

[...]

> > This is the sort of 'brave' move that reminds me (at a much smaller
> > scale, I agree) to the spatial nautilus business. I haven't met a single
> > person that wasn't upset by that change. And that was shoved down
> > people's throats rather unceremoniously. 
> 
> My name is seth vidal. I was not upset by spatial nautilus.
> 
> pleased to meet you.

Neither was I.

BTW, what is nautilus anyway?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From cmadams at hiwaay.net  Tue Jul 12 13:47:32 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 12 Jul 2005 08:47:32 -0500
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121139573.11210.19.camel@dimi>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
Message-ID: <20050712134732.GA1355467@hiwaay.net>

Once upon a time, Dimi Paun <dimi at lattica.com> said:
> Oh, not this again! We turn a perfectly useful thing in another
> "configure yourself" answer. Are we going back to the infinitely
> configurable but useless desktop?

Obviosuly not; if it were configurable, the contents of the menu would
be configurable and not compiled-in.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From cmadams at hiwaay.net  Tue Jul 12 13:54:56 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 12 Jul 2005 08:54:56 -0500
Subject: rawhide report: 20050711 changes
In-Reply-To: <604aa791050711220855201496@mail.gmail.com>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi>
	<604aa791050711220855201496@mail.gmail.com>
Message-ID: <20050712135456.GB1355467@hiwaay.net>

Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> Is the action you are doing in a terminal.. simply because you are use
> to the cmdline.. and refuse to actually use the desktop components?  I
> know i open a terminal simply because I'm use to driving around my
> filesystem in bash. This is not however something I expect normal
> people to want to do.

I use the terminal because I spend a significant amount of my time
remotely accessing other systems and devices.  And while Juniper has a
web GUI that looks somewhat useful (on the J series anyway), Cisco's is
horrible and buggy.  Tru64's web GUI is weird (and in my servers,
disabled), I never tried the one on Solaris, and RHEL doesn't have one,
so I'll be using a terminal constantly for the foreseeable future.

Remember, the terminal is not just for local access; it is also pretty
much a requirement for many types of remote access (telnet/SSH and
serial console).  There is nothing you can do with a local desktop to
replace that need.

However, I don't use right-click to get a terminal.  I add a panel
button for xterm (not gnome-terminal) and set my default desktop up to
include 2 tall xterms at login.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From overholt at redhat.com  Tue Jul 12 14:11:33 2005
From: overholt at redhat.com (Andrew Overholt)
Date: Tue, 12 Jul 2005 10:11:33 -0400
Subject: New eclipse
In-Reply-To: <5cf776b805071204274df1a03c@mail.gmail.com>
References: <5cf776b805071204274df1a03c@mail.gmail.com>
Message-ID: <1121177493.3601.3.camel@localhost.localdomain>

Hi,

On Tue, 2005-12-07 at 07:27 -0400, mbneto wrote:
> 
> the 3.1 eclipse was released a few days ago and I was wondering when
> will it be available in rawhide and FC4.

It's currently in rawhide and we're just waiting for the gcc update to
FC4 before pushing it as an FC4 update.

Andrew



From ph18 at cornell.edu  Tue Jul 12 14:13:30 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 12 Jul 2005 10:13:30 -0400
Subject: No more right click terminal
In-Reply-To: <1121143049.3521.16.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
Message-ID: <42D3D00A.8010802@cornell.edu>

Jesse Keating wrote:

>I would really like to open this up to the discussion for the users and
>developers of Fedora.  This feature is very ingrained in a lot of our
>muscle memories, deeply embedded in our internal and external
>documentation for not just end users but entry level admins, group
>admins, and a myriad of folks that really do have a use for the
>terminal.  Sure you can just as easily get to it by selecting it from a
>menu, so that actually goes in my favor.  If we're trying to 'protect'
>the user, why have it in the menu at all?  If the end user that Gnome
>seems to care about won't notice, why not leave it so that the people
>who have a clue and have the capability of helping out don't get pissed
>off by yet another 'lets break history in favor of some "usability" we
>think is right for the fabled holy grail of an end user'.
>
>  
>
    A general complaint I've had about 'desktop-oriented' Linux 
distributions is that the GUI tries to push people into half-baked GUI 
apps and discourage people from opening a terminal window,  which is 
usually easier to use because there are fewer bugs in the command line 
programs -- I've got an older machine where my usual way of getting an 
xterm is Alt-F2 "xterm".

    Given that FC is a distribution aimed at Linux enthusiasts,  and not 
a 'windows-killer' aimed at novices,  I think the command line should be 
getting more real estate on the screen,  not less.



From david at fubar.dk  Tue Jul 12 14:18:52 2005
From: david at fubar.dk (David Zeuthen)
Date: Tue, 12 Jul 2005 10:18:52 -0400
Subject: No more right click terminal
In-Reply-To: <42D3D00A.8010802@cornell.edu>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D3D00A.8010802@cornell.edu>
Message-ID: <1121177932.3683.13.camel@daxter.boston.redhat.com>

On Tue, 2005-07-12 at 10:13 -0400, Paul A Houle wrote:
>     Given that FC is a distribution aimed at Linux enthusiasts,  and not 
> a 'windows-killer' aimed at novices,  I think the command line should be 
> getting more real estate on the screen,  not less.

Hardly given. See http://fedora.redhat.com/about/objectives.html

    David




From alan at redhat.com  Tue Jul 12 14:24:06 2005
From: alan at redhat.com (Alan Cox)
Date: Tue, 12 Jul 2005 10:24:06 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121172854.12742.2.camel@cutter>
References: <1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan>
	<1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi> <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi> <1121145904.10435.19.camel@cutter>
	<1121171847.11210.54.camel@dimi> <1121172854.12742.2.camel@cutter>
Message-ID: <20050712142406.GB30030@devserv.devel.redhat.com>

On Tue, Jul 12, 2005 at 08:54:14AM -0400, seth vidal wrote:
> At the end of the day fedora follows the decisions of upstream and
> shouldn't be patching in items like a gnome-terminal on the desktop root
> right-click menu.

The focus should be on the real issue - the state of menu editing. If I need
gnome-terminal on my root menu I can probably operate a menu editor.



From skvidal at phy.duke.edu  Tue Jul 12 14:28:47 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 12 Jul 2005 10:28:47 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <20050712142406.GB30030@devserv.devel.redhat.com>
References: <1121128263.7251.7.camel@goose>
	<1121130897.4423.10.camel@ignacio.lan> <1121139573.11210.19.camel@dimi>
	<604aa79105071121247b3616b7@mail.gmail.com>
	<1121142896.11210.36.camel@dimi> <1121143246.10435.9.camel@cutter>
	<1121145260.11210.41.camel@dimi> <1121145904.10435.19.camel@cutter>
	<1121171847.11210.54.camel@dimi> <1121172854.12742.2.camel@cutter>
	<20050712142406.GB30030@devserv.devel.redhat.com>
Message-ID: <1121178527.3293.2.camel@cutter>

On Tue, 2005-07-12 at 10:24 -0400, Alan Cox wrote:
> On Tue, Jul 12, 2005 at 08:54:14AM -0400, seth vidal wrote:
> > At the end of the day fedora follows the decisions of upstream and
> > shouldn't be patching in items like a gnome-terminal on the desktop root
> > right-click menu.
> 
> The focus should be on the real issue - the state of menu editing. If I need
> gnome-terminal on my root menu I can probably operate a menu editor.

no disagreement there. But does it make sense to discuss menu editing
here and not on a gnome list?
-sv




From rms at 1407.org  Tue Jul 12 14:39:19 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 12 Jul 2005 15:39:19 +0100
Subject: No more right click terminal
In-Reply-To: <42D3D00A.8010802@cornell.edu>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D3D00A.8010802@cornell.edu>
Message-ID: <1121179159.6545.65.camel@roque>

On Tue, 2005-07-12 at 10:13 -0400, Paul A Houle wrote:
>     Given that FC is a distribution aimed at Linux enthusiasts,  and not 
> a 'windows-killer' aimed at novices,  I think the command line should be 
> getting more real estate on the screen,  not less.

I think a better case for the command line has been made at
http://www.linuxcommand.org/learning_the_shell.php

and the "CLI Magic" series by Joe Barr.

Hiding the command line, one of the strongest features of UNIX-like
operating systems, reveals true crack-pot, at least.

Having an easy access to a terminal emulator by clicking in the root
window shouldn't be discouraged.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/8a366e1f/attachment.sig>

From jspaleta at gmail.com  Tue Jul 12 15:17:12 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 12 Jul 2005 11:17:12 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>
References: <604aa79105071121247b3616b7@mail.gmail.com>
	<200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>
Message-ID: <604aa7910507120817428a81d0@mail.gmail.com>

On 7/12/05, Horst von Brand <vonbrand at inf.utfsm.cl> wrote:
> Right. And changing the desktop background is a regular operation,
> /absolutely requiring/ an entry there.

Since changing the desktop wallpaper is sort of inherently a "desktop"
operation, you are after all manipulating the "desktop" with that
command, it seems perfectly logical to me to expose that operation via
interaction with context menu on the "desktop".  Just like I expect
gnome-terminal to have some "terminal" operations in its right-click
menu of the "terminal". I expect to have "desktop" operations in the
context menu of the "desktop"  If there were more "desktop"
manipulation operations competing for space in the menus then you
could have a nice lively discussion about the relative merits of how
to expose specific operations as context menu items. But there aren't
that many desktop specific operations to choose from really. At most
there is room to discuss the inclusion of creating a new server
connection to parallel the new folder and file creation, but I
honestly can't think of any other desktop specific operation that
manipulates the appearence and contents of the desktop.

I don't really think opening any specific app being it a terminal or
xchat or a web browser or email or whatever... is inherently a
"desktop" operation.  If the desktop is suppose have an open terminal
item in its context menu.. then my web browser  could also have an
open terminal right click item and so could my mail client. My mouse
spends more time hovering over an email or web page than it does
hovering over blank desktop.  Hell,... make "open a terminal" a
standard item in every context and File menu for all gtk apps, if
getting access to a terminal is really more important than getting
access to any other application that lives in the menus or as laucher
panel items.  In fact, forget the terminal.... how about we hardwire
gtk to make "open emacs" the top listing in every menu.

> 
> Oh, come on. Sure, GUIs /can/ be used in a just-point&drool way, but the
> commands are what makes *ix powerful.

Then use the menus or set the keyboard binding to launch the terminal.
There's no reason that "powerful" commands need to be accessible via
the desktop context menu... by default.

-jef



From pnasrat at redhat.com  Tue Jul 12 15:34:34 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Tue, 12 Jul 2005 11:34:34 -0400
Subject: No more right click terminal
In-Reply-To: <1121145040.2685.16.camel@rhbw.boston.redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121145040.2685.16.camel@rhbw.boston.redhat.com>
Message-ID: <1121182474.3099.2.camel@enki.eridu>

On Tue, 2005-07-12 at 01:10 -0400, Bryan Clark wrote:
> Seriously dude if you calm down for just a little while, allowing for
> someone to respond who actually knows what happened we won't have a
> witch trial on our hands. ;-)
> 
> It's obviously not perfect yet, but GNOME is making progress to being
> both Power Tool friendly (read you) and regular person friendly (read
> hopefully everyone else).
> 
> This page describes lots of cool things you can install and use to trick
> out your GNOME DE as you might like.
> http://live.gnome.org/PowerUserTools
> 
> More specifically this page has the package for the _new_ open terminal
> menu item that actually works better in most ways than the old one.
> http://manny.cluecoder.org/packages/nautilus-open-terminal/

In which case a an Extras package would be nice to have.

Bryan, are you going to look into that?

Paul



From rms at 1407.org  Tue Jul 12 15:43:55 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 12 Jul 2005 16:43:55 +0100
Subject: rawhide report: 20050711 changes
In-Reply-To: <604aa7910507120817428a81d0@mail.gmail.com>
References: <604aa79105071121247b3616b7@mail.gmail.com>
	<200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>
	<604aa7910507120817428a81d0@mail.gmail.com>
Message-ID: <1121183035.6545.79.camel@roque>

On Tue, 2005-07-12 at 11:17 -0400, Jeff Spaleta wrote:
> I don't really think opening any specific app being it a terminal or
> xchat or a web browser or email or whatever... is inherently a
> "desktop" operation.  If the desktop is suppose have an open terminal
> item in its context menu.. 

The desktop is actually a means of interfacing the computer.
The same way I usually type nautilus /some/path, sometimes, I also like
to be able to quickly call up a terminal (another means of interfacing
the computer) and which is the quicker (Fitt's law) way to do it than
the 5th main pointer coordinate (the current pointer coordinate)?

> then my web browser  could also have an

The web browser is a means of interacting with the web. Some web
browsers have support for file:// but's merely an accidental support.


> Then use the menus or set the keyboard binding to launch the terminal.
> There's no reason that "powerful" commands need to be accessible via
> the desktop context menu... by default.

There's a huge reason to do this, along with NOT USING ~/Desktop but
$HOME as the desktop.

COHERENCE

Like the shell shows you $HOME by default, so should the Desktop.

It is so much simpler...

Rui
-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/e9498e5b/attachment.sig>

From sundaram at redhat.com  Tue Jul 12 15:47:50 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 12 Jul 2005 21:17:50 +0530
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121183035.6545.79.camel@roque>
References: <604aa79105071121247b3616b7@mail.gmail.com>	<200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>	<604aa7910507120817428a81d0@mail.gmail.com>
	<1121183035.6545.79.camel@roque>
Message-ID: <42D3E626.30303@redhat.com>

Hi

>The desktop is actually a means of interfacing the computer.
>The same way I usually type nautilus /some/path, sometimes, I also like
>to be able to quickly call up a terminal (another means of interfacing
>the computer)
>
use Alt+F2 or setup a shortcut key calls up terminal instantly
regards
Rahul



From rms at 1407.org  Tue Jul 12 15:54:25 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 12 Jul 2005 16:54:25 +0100
Subject: rawhide report: 20050711 changes
In-Reply-To: <42D3E626.30303@redhat.com>
References: <604aa79105071121247b3616b7@mail.gmail.com>
	<200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>
	<604aa7910507120817428a81d0@mail.gmail.com>
	<1121183035.6545.79.camel@roque>  <42D3E626.30303@redhat.com>
Message-ID: <1121183665.6545.91.camel@roque>

On Tue, 2005-07-12 at 21:17 +0530, Rahul Sundaram wrote:
> >The desktop is actually a means of interfacing the computer.
> >The same way I usually type nautilus /some/path, sometimes, I also like
> >to be able to quickly call up a terminal (another means of interfacing
> >the computer)
> >
> use Alt+F2 or setup a shortcut key calls up terminal instantly

Putting aside the fact that such knee-jerk answers don't help solve any
problem, I'm more than experienced to find alternative ways anyway, I
think it is a terrible mistake to "dumbify" users by making it almost
only wysiwyg, and providing little coherence.

'Mind you, to me the problem is not "not having" this root menu entry,
but a general movement towards stupidifying the GUI, and zero
educational information about the system.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/ca9888a4/attachment.sig>

From jspaleta at gmail.com  Tue Jul 12 16:01:50 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 12 Jul 2005 12:01:50 -0400
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121183035.6545.79.camel@roque>
References: <604aa79105071121247b3616b7@mail.gmail.com>
	<200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>
	<604aa7910507120817428a81d0@mail.gmail.com>
	<1121183035.6545.79.camel@roque>
Message-ID: <604aa791050712090130ec5398@mail.gmail.com>

On 7/12/05, Rui Miguel Seabra <rms at 1407.org> wrote:
> The desktop is actually a means of interfacing the computer.

I'm holding out for the neural implant interface, to throw off these
shackles of physical metaphorical constructs.

-jef"can't wait to get the tatoo on my forehead that reads "google
inside" when i finally save up enough money to get my wireless neural
implant."spaleta



From paolini at dmf.unicatt.it  Tue Jul 12 16:06:19 2005
From: paolini at dmf.unicatt.it (Maurizio Paolini)
Date: Tue, 12 Jul 2005 18:06:19 +0200
Subject: kig-python support still missing in kde 3.4.1 updates
Message-ID: <20050712160619.GA4587@pascalp.dmf.bs.unicatt.it>

Some time ago I posted in this list about a problem in
kig (missing python scripting support) related to FC4-test.

Following a kind suggestion coming from this mailing
list I then opened a bug in bugzilla (#157961) and even had an
answer from the official packager of kdeedu stating that
the problem would have been solved with the first updates
(kde 3.4.1) to FC4.

Now the updates are out, but the problem is still there.
I promptly reopened the bug report #157961 on bugzilla and tried
to contact the mantainer again, but I didn't get any
answer (this happened two or three weeks ago).

This is why I am again trying a post on this mailing list.
Do you have any suggestion on how to deal with the problem?
I know the problem is solvable, since I succeeded in building
a replacement "rpm" for kig that works fine, however I am
not capable of producing a "real" kdeedu rpm (and the corresponding
source rpm) with all the fine details, dependencies and so on.

Cheers,
Maurizio Paolini



From camilo at mesias.co.uk  Tue Jul 12 17:20:17 2005
From: camilo at mesias.co.uk (Cam)
Date: Tue, 12 Jul 2005 18:20:17 +0100
Subject: No more right click terminal
In-Reply-To: <42D39DD9.8070106@mesias.co.uk>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
Message-ID: <42D3FBD1.4090409@mesias.co.uk>

> I used that desktop menu, but I will now try to configure ctrl-shift-T 
> to open a new terminal. It's the same key sequence to open a new tab in 
> a terminal... Hope that can be made to work.

Well that didn't have the desired effect. The ctrl-shift-t for terminal 
worked but eclipsed the ctrl-shift-t meaning 'new tab' in the terminal.

How much coding would be involved in adding a 'new terminal or tab in 
terminal' keyboard shortcut? Or is that too KDE-ish and useful for Gnome?

-Cam



From kaboom at oobleck.net  Tue Jul 12 17:26:28 2005
From: kaboom at oobleck.net (Chris Ricker)
Date: Tue, 12 Jul 2005 13:26:28 -0400 (EDT)
Subject: A quick look at the yum mirrorlists
In-Reply-To: <20050711183754.785f6801@nausicaa.camperquake.de>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<20050709232016.GG31114@redhat.com>
	<1120953198.2759.6.camel@locolhost.localdomain>
	<Pine.LNX.4.63.0507111045580.32010@urd.oobleck.net>
	<20050711170907.1987c8e9@nausicaa.camperquake.de>
	<Pine.LNX.4.63.0507111230480.32010@urd.oobleck.net>
	<20050711183754.785f6801@nausicaa.camperquake.de>
Message-ID: <Pine.LNX.4.63.0507121324540.6125@urd.oobleck.net>

On Mon, 11 Jul 2005, Ralf Ertzinger wrote:

> Hi.
> 
> Chris Ricker <kaboom at oobleck.net> wrote:
> 
> > I was actually referring to the backspace borkage in vim, though
> > 
> > *ttyModes: erase ^?
> 
> I have to admit that I have not noticed anything wrong with my
> backspace in vi.

See BZ #155538

later,
chris



From jkeating at j2solutions.net  Tue Jul 12 18:06:11 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 12 Jul 2005 11:06:11 -0700
Subject: No more right click terminal
In-Reply-To: <42D39DD9.8070106@mesias.co.uk>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
Message-ID: <1121191571.25036.10.camel@prometheus.gamehouse.com>

On Tue, 2005-07-12 at 11:39 +0100, Cam wrote:
> I used that desktop menu, but I will now try to configure
> ctrl-shift-T 
> to open a new terminal. It's the same key sequence to open a new tab
> in 
> a terminal... Hope that can be made to work.
> 

Yes, I can retrain my usage.  However I'm tired of chasing the terminal
around where gnome wants to hide it.  First (well first for me) it was
on the taskbar.  Cool.  Then it moved and I found it on the menu.  Cool.
Then it moved again, and again, and again and I said 'eff it' and used
the right click option and modified all my documentation to reference
this, thinking that it has been here this long, surely it'll stay...
Especially given that people go "Oooh!  Thats handy!" every time I show
them it.

Alas no, it is now removed and it's time for 'hunt the terminal again'
for each release and then modify documentation accordingly.  It's not
nice to have an if/then block for each and every release of Fedora on
where to find the terminal.  God knows where they'll stick it next
release, however I have an idea.

-- 
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



From hcstudt at post10.tele.dk  Tue Jul 12 18:19:14 2005
From: hcstudt at post10.tele.dk (Hans Christian Studt)
Date: Tue, 12 Jul 2005 20:19:14 +0200
Subject: Reproduceable kernel crash when reading CD-RW corrupt file
Message-ID: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>

Hi,

I would like to help trace down the cause of this reproduceable kernel crash I get with kernel 2.6.12-1.1390_FC4.

How do I best do that ?

Mvh Hans Christian Studt
Mobile +45 29 23 54 14
hc[AT]studt[DOT]dk http://hc.studt.dk
Powered by Linux 2.6.11-1.27_FC3



From perbj at stanford.edu  Tue Jul 12 18:19:51 2005
From: perbj at stanford.edu (Per Bjornsson)
Date: Tue, 12 Jul 2005 11:19:51 -0700
Subject: No more right click terminal
In-Reply-To: <1121191571.25036.10.camel@prometheus.gamehouse.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
	<1121191571.25036.10.camel@prometheus.gamehouse.com>
Message-ID: <1121192391.2984.21.camel@localhost.localdomain>

On Tue, 2005-07-12 at 11:06 -0700, Jesse Keating wrote:
> Yes, I can retrain my usage.  However I'm tired of chasing the terminal
> around where gnome wants to hide it.  First (well first for me) it was
> on the taskbar.  Cool.  Then it moved and I found it on the menu.  Cool.
> Then it moved again, and again, and again and I said 'eff it' and used
> the right click option and modified all my documentation to reference
> this, thinking that it has been here this long, surely it'll stay...

When did it move from the menu? I can't remember a time when it wasn't
in System Tools > Terminal, but maybe my memory is too short? I think
that the menu is pretty much the canonical spot for finding things in
the current GUI, and dragging a menu entry to a panel if you want a
launcher for easier access really isn't that much work.

> Especially given that people go "Oooh!  Thats handy!" every time I show
> them it.

That's probably because you were teaching people stuff that involved
terminal usage. Most people can't be bothered. The reaction I have seen
from most people when they see me pop up a terminal window is just a
some combination of horror and disgust. The terminal really can't be
seen as part of the user interface for "regular" users.

No need to tell me how great the terminal is, I know, and I have a
launcher on my panel. It's not going anywhere. But I'm strange and I
know it.

> Alas no, it is now removed and it's time for 'hunt the terminal again'
> for each release and then modify documentation accordingly.  It's not
> nice to have an if/then block for each and every release of Fedora on
> where to find the terminal.  God knows where they'll stick it next
> release, however I have an idea.

Gone entirely, just to tick you off? ;)

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From jkeating at j2solutions.net  Tue Jul 12 18:42:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 12 Jul 2005 11:42:09 -0700
Subject: No more right click terminal
In-Reply-To: <1121192391.2984.21.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
	<1121191571.25036.10.camel@prometheus.gamehouse.com>
	<1121192391.2984.21.camel@localhost.localdomain>
Message-ID: <1121193729.25036.16.camel@prometheus.gamehouse.com>

On Tue, 2005-07-12 at 11:19 -0700, Per Bjornsson wrote:
> When did it move from the menu? I can't remember a time when it wasn't
> in System Tools > Terminal, but maybe my memory is too short? I think
> that the menu is pretty much the canonical spot for finding things in
> the current GUI, and dragging a menu entry to a panel if you want a
> launcher for easier access really isn't that much work.

I'm almost certain it changed locations a few times between RHL 7.2 and
FC4.  There was quite a shakeup on menu entries along that time line.

> > Especially given that people go "Oooh!  Thats handy!" every time I show
> > them it.
> 
> That's probably because you were teaching people stuff that involved
> terminal usage. Most people can't be bothered. The reaction I have seen
> from most people when they see me pop up a terminal window is just a
> some combination of horror and disgust. The terminal really can't be
> seen as part of the user interface for "regular" users.

Well yeah, the majority of the people I teach are entry level admin
types or slightly more advanced users than the secretary and need to
take advantage of some of the really useful things a Linux system can do
from the terminal.

> No need to tell me how great the terminal is, I know, and I have a
> launcher on my panel. It's not going anywhere. But I'm strange and I
> know it.

You may have a launcher, but new user Bob won't and thus I can't write
documentation assuming that he does.

-- 
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



From smooge at gmail.com  Tue Jul 12 18:35:31 2005
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 12 Jul 2005 12:35:31 -0600
Subject: No more right click terminal
In-Reply-To: <1121191571.25036.10.camel@prometheus.gamehouse.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
	<1121191571.25036.10.camel@prometheus.gamehouse.com>
Message-ID: <80d7e409050712113579c6935b@mail.gmail.com>

On 7/12/05, Jesse Keating <jkeating at j2solutions.net> wrote:
> On Tue, 2005-07-12 at 11:39 +0100, Cam wrote:
> > I used that desktop menu, but I will now try to configure
> > ctrl-shift-T
> > to open a new terminal. It's the same key sequence to open a new tab
> > in
> > a terminal... Hope that can be made to work.
> >
> 
> Yes, I can retrain my usage.  However I'm tired of chasing the terminal
> around where gnome wants to hide it.  First (well first for me) it was
> on the taskbar.  Cool.  Then it moved and I found it on the menu.  Cool.
> Then it moved again, and again, and again and I said 'eff it' and used
> the right click option and modified all my documentation to reference
> this, thinking that it has been here this long, surely it'll stay...
> Especially given that people go "Oooh!  Thats handy!" every time I show
> them it.
> 
> Alas no, it is now removed and it's time for 'hunt the terminal again'
> for each release and then modify documentation accordingly.  It's not
> nice to have an if/then block for each and every release of Fedora on
> where to find the terminal.  God knows where they'll stick it next
> release, however I have an idea.
> 

To quote someone at Red Hat: "Amen Brother." I will now have to update another
couple of internal FAQ's, train a bunch of window techs on the new place to tell
their customers for the hidden terminal, and just be plain grumpy for a bit.

On trying to get a positive outlook on this.. how does someone make a
'corporate desktop' for GNOME? If I want to push out 200 machines with
every fricking user having a
terminal icon on the background and on the menu bars.. how is that
done? I think it will
be easier to go this route and let the GNOME hackers go off mammoth
hunting for a
while... 

-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From sundaram at redhat.com  Tue Jul 12 18:36:53 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 13 Jul 2005 00:06:53 +0530
Subject: No more right click terminal
In-Reply-To: <1121193729.25036.16.camel@prometheus.gamehouse.com>
References: <1121143049.3521.16.camel@localhost.localdomain>	<42D39DD9.8070106@mesias.co.uk>	<1121191571.25036.10.camel@prometheus.gamehouse.com>	<1121192391.2984.21.camel@localhost.localdomain>
	<1121193729.25036.16.camel@prometheus.gamehouse.com>
Message-ID: <42D40DC5.3050003@redhat.com>

Hi

>You may have a launcher, but new user Bob won't and thus I can't write
>documentation assuming that he does.
>
>  
>
As a person dealing with this kind of problems in docs, I usually refer 
to it from  Main menu/Applications => System Tools => Terminal. 

regards
Rahul



From florin at andrei.myip.org  Tue Jul 12 18:37:26 2005
From: florin at andrei.myip.org (Florin Andrei)
Date: Tue, 12 Jul 2005 11:37:26 -0700
Subject: bugzilla is stuck
Message-ID: <1121193446.18388.4.camel@stantz.corp.sgi.com>

I am trying to submit a bug report related to freeradius on FC4. I enter
all the information. I click on Submit Bug.
A new window opens up, but it's empty. The bug is not submitted.
I tried to delete all cookies related to bugzilla.redhat.com, restart
Firefox, re-login to bugzilla, yadda-yadda... No improvement.

This is not the first time it's happening. Last time, I think I "fixed"
it by deleting .mozilla. That's not a pretty solution.

Anyone has any idea?...

-- 
Florin Andrei

http://florin.myip.org/



From sundaram at redhat.com  Tue Jul 12 18:38:21 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 13 Jul 2005 00:08:21 +0530
Subject: No more right click terminal
In-Reply-To: <80d7e409050712113579c6935b@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>	<42D39DD9.8070106@mesias.co.uk>	<1121191571.25036.10.camel@prometheus.gamehouse.com>
	<80d7e409050712113579c6935b@mail.gmail.com>
Message-ID: <42D40E1D.2000008@redhat.com>

Hi

>On trying to get a positive outlook on this.. how does someone make a
>'corporate desktop' for GNOME? If I want to push out 200 machines with
>every fricking user having a
>terminal icon on the background and on the menu bars.. how is that
>done? I think it will
>be easier to go this route and let the GNOME hackers go off mammoth
>hunting for a
>while... 
>
>  
>
See http://www.redhat.com/magazine/008jun05/features/sabayon/

regards
Rahul



From sundaram at redhat.com  Tue Jul 12 18:40:50 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 13 Jul 2005 00:10:50 +0530
Subject: bugzilla is stuck
In-Reply-To: <1121193446.18388.4.camel@stantz.corp.sgi.com>
References: <1121193446.18388.4.camel@stantz.corp.sgi.com>
Message-ID: <42D40EB2.4010306@redhat.com>

Florin Andrei wrote:

>I am trying to submit a bug report related to freeradius on FC4. I enter
>all the information. I click on Submit Bug.
>A new window opens up, but it's empty. The bug is not submitted.
>I tried to delete all cookies related to bugzilla.redhat.com, restart
>Firefox, re-login to bugzilla, yadda-yadda... No improvement.
>
>This is not the first time it's happening. Last time, I think I "fixed"
>it by deleting .mozilla. That's not a pretty solution.
>
>Anyone has any idea?...
>
>  
>
Not sure of the right solution but last time this happened, I fixed it 
by clearing up my browser cookies

regards
Rahul



From florin at andrei.myip.org  Tue Jul 12 18:49:44 2005
From: florin at andrei.myip.org (Florin Andrei)
Date: Tue, 12 Jul 2005 11:49:44 -0700
Subject: couple of freeradius bugs, seem spec-related
Message-ID: <1121194184.18388.14.camel@stantz.corp.sgi.com>

Ok, since I can't submit stuff to Bugzilla for now (see my previous
message), let me send it out this way, maybe it catches someone's
attention.

1. Missing rlm_ldap.so
The original FC4 freeradius doesn't have rlm_ldap.so:

$ rpm -ql freeradius | grep ldap
/etc/raddb/ldap.attrmap
/usr/share/doc/freeradius-1.0.2/rlm_ldap

However, after rebuilding the src.rpm with no changes whatsoever on my
FC4 system, the file is present in the rebuilt package:

$ rpm -qpl RPMS/i386/freeradius-1.0.2-2.i386.rpm | grep ldap
/etc/raddb/ldap.attrmap
/usr/lib/rlm_ldap-1.0.2.so
/usr/lib/rlm_ldap.so
/usr/share/doc/freeradius-1.0.2/rlm_ldap

What's strange is that openldap-devel is mentioned in the BuildRequires,
so probably there is an intention to provide LDAP authentication in the
package, but the package provides no LDAP module.


2. Missing -devel dependency
libtool-ltdl-devel is not mentioned in BuildRequires, yet freeradius
src.rpm requires it. On my system, that lib is missing, so the src.rpm
rebuild fails.
This is not a heavily customized system, it is a Custom install, but
while installing the system I selected the development packages group,
among other things, and did not unselect anything.

-- 
Florin Andrei

http://florin.myip.org/



From paul at city-fan.org  Tue Jul 12 18:51:49 2005
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 12 Jul 2005 19:51:49 +0100
Subject: bugzilla is stuck
In-Reply-To: <1121193446.18388.4.camel@stantz.corp.sgi.com>
References: <1121193446.18388.4.camel@stantz.corp.sgi.com>
Message-ID: <1121194310.18275.12.camel@laurel.intra.city-fan.org>

On Tue, 2005-07-12 at 11:37 -0700, Florin Andrei wrote:
> I am trying to submit a bug report related to freeradius on FC4. I enter
> all the information. I click on Submit Bug.
> A new window opens up, but it's empty. The bug is not submitted.
> I tried to delete all cookies related to bugzilla.redhat.com, restart
> Firefox, re-login to bugzilla, yadda-yadda... No improvement.
> 
> This is not the first time it's happening. Last time, I think I "fixed"
> it by deleting .mozilla. That's not a pretty solution.
> 
> Anyone has any idea?...

This happened to me last time too. "Expert mode" worked though.

Paul.
-- 
Paul Howarth <paul at city-fan.org>



From florin at andrei.myip.org  Tue Jul 12 18:58:20 2005
From: florin at andrei.myip.org (Florin Andrei)
Date: Tue, 12 Jul 2005 11:58:20 -0700
Subject: couple of freeradius bugs, seem spec-related
In-Reply-To: <1121194184.18388.14.camel@stantz.corp.sgi.com>
References: <1121194184.18388.14.camel@stantz.corp.sgi.com>
Message-ID: <1121194700.18388.16.camel@stantz.corp.sgi.com>

On Tue, 2005-07-12 at 11:49 -0700, Florin Andrei wrote:

> 1. Missing rlm_ldap.so

I "fixed" the bugzilla issue so I submitted a bug report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163072

> 2. Missing -devel dependency

I don't really care about this one.

-- 
Florin Andrei

http://florin.myip.org/



From florin at andrei.myip.org  Tue Jul 12 18:59:15 2005
From: florin at andrei.myip.org (Florin Andrei)
Date: Tue, 12 Jul 2005 11:59:15 -0700
Subject: bugzilla is stuck
In-Reply-To: <42D40EB2.4010306@redhat.com>
References: <1121193446.18388.4.camel@stantz.corp.sgi.com>
	<42D40EB2.4010306@redhat.com>
Message-ID: <1121194755.18388.18.camel@stantz.corp.sgi.com>

On Wed, 2005-07-13 at 00:10 +0530, Rahul Sundaram wrote:
> Florin Andrei wrote:
> 
> >I am trying to submit a bug report related to freeradius on FC4. I enter
> >all the information. I click on Submit Bug.
> >A new window opens up, but it's empty. The bug is not submitted.
> >I tried to delete all cookies related to bugzilla.redhat.com, restart
> >Firefox, re-login to bugzilla, yadda-yadda... No improvement.

> Not sure of the right solution but last time this happened, I fixed it 
> by clearing up my browser cookies

Ok, that "fixed" it, but <sigh> now I lost a bunch of passwords and
stuff like that.

Seems like it's a bugzilla bug, after all.

-- 
Florin Andrei

http://florin.myip.org/



From smooge at gmail.com  Tue Jul 12 19:47:15 2005
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 12 Jul 2005 13:47:15 -0600
Subject: No more right click terminal
In-Reply-To: <42D40E1D.2000008@redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
	<1121191571.25036.10.camel@prometheus.gamehouse.com>
	<80d7e409050712113579c6935b@mail.gmail.com>
	<42D40E1D.2000008@redhat.com>
Message-ID: <80d7e40905071212476c6009f1@mail.gmail.com>

Thanks! The second most common question in our queue seems to be (Fed Core 3
wasnt approved for usage. Fed Core 4 was and it is coming up)

"How do I turn off the stupid new window for every directory." Being
able to push this out to a bunch of people will definately cut down
these questions

On 7/12/05, Rahul Sundaram <sundaram at redhat.com> wrote:
> Hi
> 
> >On trying to get a positive outlook on this.. how does someone make a
> >'corporate desktop' for GNOME? If I want to push out 200 machines with
> >every fricking user having a
> >terminal icon on the background and on the menu bars.. how is that
> >done? I think it will
> >be easier to go this route and let the GNOME hackers go off mammoth
> >hunting for a
> >while...
> >
> >
> >
> See http://www.redhat.com/magazine/008jun05/features/sabayon/
> 
> regards
> Rahul
> 


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From lamont at gurulabs.com  Tue Jul 12 19:54:23 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 12 Jul 2005 13:54:23 -0600
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121122596.21980.4.camel@amd64.mattlauterbach.com>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<200507112003.31480.lamont@gurulabs.com>
	<1121122596.21980.4.camel@amd64.mattlauterbach.com>
Message-ID: <200507121354.30508.lamont@gurulabs.com>

On Monday 11 July 2005 04:56pm, Matthew E. Lauterbach wrote:
[SNIP]
> Have you checked KDE lately?  I have Konsole on right-click in FC4's KDE
> 3.4.1.  It's a good thing.

Ah, you are correct.  I am using the kde-redhat packages and they too have 
Konsole on the desktop context menu.  I hadn't tried it in KDE since before 
3.4 (which is when I started using the kde-redhat packages instead of 
rebuilding my own).  It's a good thing.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/7b129ba0/attachment.sig>

From aoliva at redhat.com  Tue Jul 12 19:55:08 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 12 Jul 2005 16:55:08 -0300
Subject: Reproduceable kernel crash when reading CD-RW corrupt file
In-Reply-To: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
References: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
Message-ID: <or64vf3ilf.fsf@livre.redhat.lsd.ic.unicamp.br>

On Jul 12, 2005, Hans Christian Studt <hcstudt at post10.tele.dk> wrote:

> I would like to help trace down the cause of this reproduceable
> kernel crash I get with kernel 2.6.12-1.1390_FC4.

> How do I best do that ?

Search bugzilla, tune into the corresponding bug, read the available
info (you'll find the latest postings enlightening) and go for it.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From perbj at stanford.edu  Tue Jul 12 19:56:22 2005
From: perbj at stanford.edu (Per Bjornsson)
Date: Tue, 12 Jul 2005 12:56:22 -0700
Subject: No more right click terminal
In-Reply-To: <80d7e40905071212476c6009f1@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
	<1121191571.25036.10.camel@prometheus.gamehouse.com>
	<80d7e409050712113579c6935b@mail.gmail.com>
	<42D40E1D.2000008@redhat.com>
	<80d7e40905071212476c6009f1@mail.gmail.com>
Message-ID: <1121198182.2984.31.camel@localhost.localdomain>

On Tue, 2005-07-12 at 13:47 -0600, Stephen J. Smoogen wrote:
> Thanks! The second most common question in our queue seems to be (Fed Core 3
> wasnt approved for usage. Fed Core 4 was and it is coming up)
> 
> "How do I turn off the stupid new window for every directory." Being
> able to push this out to a bunch of people will definately cut down
> these questions

Use Sabayon for this too? In a File manager (Nautilus) window,
Edit>Preferences, in the Behavior tab, there's a checkbox labeled
"Always open in browser windows". Check it, and spatial Nautilus is no
more.

However, since a lot of people who have actually bothered to try it seem
to like spatial Nautilus a lot (nowadays i actually get really annoyed
by the clumsiness of navigational file managers), maybe just put this in
a FAQ list instead? It seems that the "spatial" behavior isn't for
everyone, but for lots of people it actually turns out to be a pretty
cool feature.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From sundaram at redhat.com  Tue Jul 12 19:58:32 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 13 Jul 2005 01:28:32 +0530
Subject: No more right click terminal
In-Reply-To: <1121198182.2984.31.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>	<42D39DD9.8070106@mesias.co.uk>	<1121191571.25036.10.camel@prometheus.gamehouse.com>	<80d7e409050712113579c6935b@mail.gmail.com>	<42D40E1D.2000008@redhat.com>	<80d7e40905071212476c6009f1@mail.gmail.com>
	<1121198182.2984.31.camel@localhost.localdomain>
Message-ID: <42D420E8.1030508@redhat.com>

Hi

>However, since a lot of people who have actually bothered to try it seem
>to like spatial Nautilus a lot (nowadays i actually get really annoyed
>by the clumsiness of navigational file managers), maybe just put this in
>a FAQ list instead? It seems that the "spatial" behavior isn't for
>everyone, but for lots of people it actually turns out to be a pretty
>cool feature.
>
>/Per
>  
>
Thats what Red Hat did incidentally . Pushed out a FAQ even before RHEL 
4 was released. So users try it and decide for themselves what they want 
to do

regards
Rahul



From arjanv at redhat.com  Tue Jul 12 20:10:37 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 12 Jul 2005 22:10:37 +0200
Subject: Reproduceable kernel crash when reading CD-RW corrupt file
In-Reply-To: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
References: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
Message-ID: <1121199037.3171.42.camel@laptopd505.fenrus.org>

On Tue, 2005-07-12 at 20:19 +0200, Hans Christian Studt wrote:
> Hi,
> 
> I would like to help trace down the cause of this reproduceable kernel crash I get with kernel 2.6.12-1.1390_FC4.
> 
> How do I best do that ?

how big is the file in question?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/cbcf8cf9/attachment.sig>

From ivazquez at ivazquez.net  Tue Jul 12 20:14:30 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 12 Jul 2005 16:14:30 -0400
Subject: No more right click terminal
In-Reply-To: <80d7e40905071212476c6009f1@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>
	<1121191571.25036.10.camel@prometheus.gamehouse.com>
	<80d7e409050712113579c6935b@mail.gmail.com>
	<42D40E1D.2000008@redhat.com>
	<80d7e40905071212476c6009f1@mail.gmail.com>
Message-ID: <1121199270.4423.27.camel@ignacio.lan>

On Tue, 2005-07-12 at 13:47 -0600, Stephen J. Smoogen wrote:
> Thanks! The second most common question in our queue seems to be (Fed Core 3
> wasnt approved for usage. Fed Core 4 was and it is coming up)
> 
> "How do I turn off the stupid new window for every directory." Being
> able to push this out to a bunch of people will definately cut down
> these questions

Double-middle-clicking will close the existing window when it opens the
new one.

Although sometimes I do think it might be useful to have Nautilus open
the new folder in the same window.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/030490f4/attachment.sig>

From lamont at gurulabs.com  Tue Jul 12 20:32:30 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 12 Jul 2005 14:32:30 -0600
Subject: rawhide report: 20050711 changes
In-Reply-To: <1121145904.10435.19.camel@cutter>
References: <200507111137.j6BBbjNg016242@porkchop.devel.redhat.com>
	<1121145260.11210.41.camel@dimi> <1121145904.10435.19.camel@cutter>
Message-ID: <200507121432.34424.lamont@gurulabs.com>

On Monday 11 July 2005 11:25pm, seth vidal wrote:
> On Tue, 2005-07-12 at 01:14 -0400, Dimi Paun wrote:
> > Glad to hear that. But this is missing the point -- forcing such
> > preferences onto others is not right, and the people that don't like
> > this behavior (and let me tell you, in my experience they are the vast
> > majority, with the minority being ambivalent, no real fans AFAIK)
> > are going to be rightfully upset. But I digress, if folks didn't figure
> > it by now that this is not the way to make friends...
>
> 1. I think you're confusing vocal contingent on /. and osnews with
> 'majority'

I do not read /. nor osnews nor [insert biased "tech" news feed here].  I 
would say that the vast majority (like 98%) of people who I run into (at 
least hundreds if not thousands per year) love that it is as easy to open up 
a terminal as right-click and pick it.  This is true of newbs and vets alike.

BTW: I do not think a context-menu is a "hidden" menu, either.  Everyone knows 
and has used context menus for so long now, that it is not something 
mysterious.  Placing options on a context menu does not mean they are hidden.

> 2. it's not about forcing preferences it is about making sure the code
> is maintainable and not riddled with exceptions for corner cases and
> optional menus and ridiculous configuration dialogs.

If I wanted my computer experience to be dictated to me, I could either back 
Microsoft's Trusted Computing Initiative ("Trusted", my a...) or I can use 
GNOME.  Thank you for clarifying this.

Seriously, though, I know that I can customize GNOME to work the way I want it 
to, but the effort required to be able to do so is just plain not worth it.  
Not when you compare it with KDE, XFCE, Fluxbox or even EvilWM (which you 
have to recompile to change almost anything).

I do not want to recompile GNOME or Nautilus simply to get a menu or a menu 
item back.  I do not want to have to go get some extra program and build my 
own package for GNOME tweaking, either (yes, I know gconf is there).  I can't 
imagine many GNOME users who would prefer to do things this way.  At the very 
least, I think such tools should be in Fedora Extras.

> If you really want to learn more about how these decisions get made and
> maybe help with them then go be involved in gnome development. But
> complaining on fedora-devel-list isn't going to help.

Excellent suggestion.

If I thought GNOME was headed in a useful direction (I never have, but I do 
use it regularly along with KDE and fluxbox on different systems) and I could 
find time to work in Yet Another Project (YAP?), I might.

I work with a lot of systems.  Every week, I sit down to machines with fresh 
installations and am confronted by the defaults.  I already "automatically" 
make 5 or 6 changes to GNOME when I get a fresh install and I just live with 
the rest of the things that bug me.  I only change 1 thing in KDE (Focus 
Follows Mouse, the right way to do it :) for usability.  Sure, on any 
environment that I am going to have around for a while I move the bars around 
and customize the launchers and the background and the look-n-feel and...but 
even on those systems, having easy access to the shell is handy (this 
notebook has at least a dozen open right now).
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/679ce4ad/attachment.sig>

From rms at 1407.org  Tue Jul 12 21:40:10 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 12 Jul 2005 22:40:10 +0100
Subject: Reproduceable kernel crash when reading CD-RW corrupt file
In-Reply-To: <1121199037.3171.42.camel@laptopd505.fenrus.org>
References: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
	<1121199037.3171.42.camel@laptopd505.fenrus.org>
Message-ID: <1121204410.2884.6.camel@roque>

On Tue, 2005-07-12 at 22:10 +0200, Arjan van de Ven wrote:
> On Tue, 2005-07-12 at 20:19 +0200, Hans Christian Studt wrote:
> > Hi,
> > 
> > I would like to help trace down the cause of this reproduceable kernel crash I get with kernel 2.6.12-1.1390_FC4.
> > 
> > How do I best do that ?
> 
> how big is the file in question?

I don't know if that's the real problem.
I've been having kernel stack trace dumps on boot in FC4, if I boot with
an original *audio* CD (Yes, CompactDisc AudioCD, not any Corrupt Disc
crapware).

This on two very different machines, so I suppose there's some problem.
I'm querying bugzilla to check if it's a known problem.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/85da005e/attachment.sig>

From davej at redhat.com  Tue Jul 12 21:44:30 2005
From: davej at redhat.com (Dave Jones)
Date: Tue, 12 Jul 2005 17:44:30 -0400
Subject: Reproduceable kernel crash when reading CD-RW corrupt file
In-Reply-To: <1121204410.2884.6.camel@roque>
References: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
	<1121199037.3171.42.camel@laptopd505.fenrus.org>
	<1121204410.2884.6.camel@roque>
Message-ID: <20050712214429.GA17806@redhat.com>

On Tue, Jul 12, 2005 at 10:40:10PM +0100, Rui Miguel Seabra wrote:
 > On Tue, 2005-07-12 at 22:10 +0200, Arjan van de Ven wrote:
 > > On Tue, 2005-07-12 at 20:19 +0200, Hans Christian Studt wrote:
 > > > Hi,
 > > > 
 > > > I would like to help trace down the cause of this reproduceable kernel crash I get with kernel 2.6.12-1.1390_FC4.
 > > > 
 > > > How do I best do that ?
 > > 
 > > how big is the file in question?
 > 
 > I don't know if that's the real problem.
 > I've been having kernel stack trace dumps on boot in FC4, if I boot with
 > an original *audio* CD (Yes, CompactDisc AudioCD, not any Corrupt Disc
 > crapware).
 > 
 > This on two very different machines, so I suppose there's some problem.
 > I'm querying bugzilla to check if it's a known problem.

It is. Fix should be in a kernel update out (hopefully) later today.
It's also a Fedora specific bug. Linus' tree is unaffected.

		Dave



From rms at 1407.org  Tue Jul 12 21:54:35 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 12 Jul 2005 22:54:35 +0100
Subject: Reproduceable kernel crash when reading CD-RW corrupt file
In-Reply-To: <20050712214429.GA17806@redhat.com>
References: <20050712181914.76C9247FE9C@pfepa.post.tele.dk>
	<1121199037.3171.42.camel@laptopd505.fenrus.org>
	<1121204410.2884.6.camel@roque>  <20050712214429.GA17806@redhat.com>
Message-ID: <1121205275.2884.8.camel@roque>

On Tue, 2005-07-12 at 17:44 -0400, Dave Jones wrote:
> On Tue, Jul 12, 2005 at 10:40:10PM +0100, Rui Miguel Seabra wrote:
>  > On Tue, 2005-07-12 at 22:10 +0200, Arjan van de Ven wrote:
>  > > On Tue, 2005-07-12 at 20:19 +0200, Hans Christian Studt wrote:
>  > > > Hi,
>  > > > 
>  > > > I would like to help trace down the cause of this reproduceable kernel crash I get with kernel 2.6.12-1.1390_FC4.
>  > > > 
>  > > > How do I best do that ?
>  > > 
>  > > how big is the file in question?
>  > 
>  > I don't know if that's the real problem.
>  > I've been having kernel stack trace dumps on boot in FC4, if I boot with
>  > an original *audio* CD (Yes, CompactDisc AudioCD, not any Corrupt Disc
>  > crapware).
>  > 
>  > This on two very different machines, so I suppose there's some problem.
>  > I'm querying bugzilla to check if it's a known problem.
> 
> It is. Fix should be in a kernel update out (hopefully) later today.
> It's also a Fedora specific bug. Linus' tree is unaffected.

Yup. Found it:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162347

R

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050712/eda1ddf4/attachment.sig>

From mailman at hanez.org  Wed Jul 13 00:14:38 2005
From: mailman at hanez.org (Johannes Findeisen)
Date: Wed, 13 Jul 2005 02:14:38 +0200
Subject: Kernel panic in 2.6.11-1.35_FC3@i686
Message-ID: <1121213678.4720.7.camel@phantom.wg.xw3.org>

Hello all,

just got this kernel panic right after updating Fedora core 3 to
2.6.11-1.35_FC3. I am running Fedora Core 3 for x86 on an AMD64 machine
- if this helps?. Since i have no serial console i could not copy and
paste the panic message, so i have made a photo which you can see at:

http://hanez.org/images/content/kernelpanic.jpg

The following package is what i am talking about: 

kernel-2.6.11-1.35_FC3.i686.rpm

Please tell me how i could debug such things better in the future. I
really want to understand the way developers are handling this.

I hope this helps.

Regards,
Johannes Findeisen



From bbbush.yuan at gmail.com  Wed Jul 13 01:07:47 2005
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Wed, 13 Jul 2005 09:07:47 +0800
Subject: rawhide report: 20050711 changes
In-Reply-To: <604aa7910507120817428a81d0@mail.gmail.com>
References: <604aa79105071121247b3616b7@mail.gmail.com>
	<200507121334.j6CDYp1g005969@laptop11.inf.utfsm.cl>
	<604aa7910507120817428a81d0@mail.gmail.com>
Message-ID: <76e72f80050712180771e64336@mail.gmail.com>

2005/7/12, Jeff Spaleta <jspaleta at gmail.com>:
> 
> Since changing the desktop wallpaper is sort of inherently a "desktop"
> operation, you are after all manipulating the "desktop" with that
> 
> I don't really think opening any specific app being it a terminal or
> xchat or a web browser or email or whatever... is inherently a
> "desktop" operation.  If the desktop is suppose have an open terminal

I use Cygwin in windows these days. Of course I have to get used to
clicking icons on the menu bar, instead of context menu. I cannot see
the difference. Clicking the icon may be much easier since you don't
have to show the desktop before operation. But then I remember that I
always use half-width menu bar in Gnome, which will leave a small
blank space in the screen corner. I click it frequently to open a
terminal :)

Why cannot there be launchers in context menu of desktop? It's a
policy, not a mechanism, right?

Why cannot there be terminal shortcuts in context menu of folders?
They are perfectly related.


-- 
bbbush ^_^



From pjones at redhat.com  Wed Jul 13 01:59:43 2005
From: pjones at redhat.com (Peter Jones)
Date: Tue, 12 Jul 2005 21:59:43 -0400
Subject: A quick look at the yum mirrorlists
In-Reply-To: <0cb50fed9dfd0b265ea965511a42a3ea@silveroaks.com>
References: <20050710022058.F3C9A737DA@hormel.redhat.com>
	<0cb50fed9dfd0b265ea965511a42a3ea@silveroaks.com>
Message-ID: <1121219983.4128.4.camel@localhost.localdomain>

On Mon, 2005-07-11 at 17:36 -0500, chasd at silveroaks.com wrote:

> Interesting question, is FC on PPC likely to suffer the same as ia64 
> and SPARC?
> Or superseded by ppc64?

Well, RHEL on ppc/ppc64 will certainly continue to happen.  FC on it
will be dependent on the same things it's always depended on -- enough
people willing to spend the time to make it work.

-- 
        Peter



From cmadams at hiwaay.net  Wed Jul 13 02:27:10 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 12 Jul 2005 21:27:10 -0500
Subject: Kernel crashes with FC3 (i386) and FC4 (x86_64)
Message-ID: <20050713022710.GE1200596@hiwaay.net>

I've got an Athlon64 system that is stable when running FC3 (i386) with
the original kernel, 2.6.9-1.667, but crashes with anything newer.  I
loaded FC4 (x86_64) on it and it crashes there as well.

It crashes under various things that cause a load: rsyncing Fedora
mirrors, playing bzflag, transcoding video, etc.  I've also had some
crashes while web browsing.

Under the FC3 2.6.11-1.35_FC3 kernel, I get:

kernel BUG at mm/rmap.c:482! 
invalid operand: 0000 [#1]

every time it crashes.  I set up a serial console so I can capture
messages while in X.  However, the crashes in FC4/x86_64 didn't even
give me an oops.

One odd thing about an FC4 crash playing bzflag (against some "bot"
tanks): it froze after I fired a shot (all the tanks and other video
stopped moving), but I still heard the sounds die away.  I didn't get an
oops, and even magic-SysRq (or serial break) didn't respond.

It doesn't appear to be a RAM problem; it ran clean with memtest86+ for
24 hours.

Another odd thing with FC4/x86_64: if I enable "Cool & Quiet" in the
BIOS, I get random segfaults during boot.  If I turn it off, powernow-k8
complains during boot, but the system runs (for a little bit anyway).

I opened a bugzilla about this a while back.  I closed it when I though
it was working, but it was still crashing (I just hadn't done much for a
few days I guess).  I re-opened it and attached some more crash
messages; it is:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159364

At this point, I'd be happy to find out it is bad hardware so I could
replace it and move on.  However, I can't afford to throw it all away
without knowing which part is bad.

Suggestions?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From paul at cypherpunks.ca  Wed Jul 13 02:55:41 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Wed, 13 Jul 2005 04:55:41 +0200 (CEST)
Subject: A quick look at the yum mirrorlists (fwd)
Message-ID: <Pine.LNX.4.63.0507130454550.5477@tla.xelerance.com>

On Tue, 12 Jul 2005, Peter Jones wrote:

> On Mon, 2005-07-11 at 17:36 -0500, chasd at silveroaks.com wrote:
> 
>> Interesting question, is FC on PPC likely to suffer the same as ia64
>> and SPARC?
>> Or superseded by ppc64?
> 
> Well, RHEL on ppc/ppc64 will certainly continue to happen.  FC on it
> will be dependent on the same things it's always depended on -- enough
> people willing to spend the time to make it work.

A broadcom driver for the onboard wirless of the G4 ibooks would help me
to keep such a willingnes. Without wireless, Fedora on these machines will
be nothing more then academic interest or nerdiness.

Paul
-- 

   "I am not even supposed to be here today!"  -- Clerk



From danfr at matrix.co.il  Wed Jul 13 07:14:20 2005
From: danfr at matrix.co.il (Dan Fruehauf)
Date: Wed, 13 Jul 2005 10:14:20 +0300
Subject: Kernel panic in 2.6.11-1.35_FC3@i686
In-Reply-To: <1121213678.4720.7.camel@phantom.wg.xw3.org>
References: <1121213678.4720.7.camel@phantom.wg.xw3.org>
Message-ID: <1121238860.3383.10.camel@isz>

Johannes,
This looks like your kernel is unable to mount your root filesystem.
I'd suggest trying to re-run mkinitrd and create one suitable for your
system.
Before the panic you can see that initrd has troubles switching to your
new root that perhaps wasn't mounted successfully.

I got something similar with a Xen0 kernel under VMWare while running
with a SCSI disk. The driver wasn't loaded well and a similar panic
followed.

On Wed, 2005-07-13 at 02:14 +0200, Johannes Findeisen wrote:
> Hello all,
> 
> just got this kernel panic right after updating Fedora core 3 to
> 2.6.11-1.35_FC3. I am running Fedora Core 3 for x86 on an AMD64 machine
> - if this helps?. Since i have no serial console i could not copy and
> paste the panic message, so i have made a photo which you can see at:
> 
> http://hanez.org/images/content/kernelpanic.jpg
> 
> The following package is what i am talking about: 
> 
> kernel-2.6.11-1.35_FC3.i686.rpm
> 
> Please tell me how i could debug such things better in the future. I
> really want to understand the way developers are handling this.
> 
> I hope this helps.
> 
> Regards,
> Johannes Findeisen
> 
-- 
Dan Fruehauf
Matrix IT, Linux Consulting



From erdinc at prosoft.com.tr  Wed Jul 13 07:51:15 2005
From: erdinc at prosoft.com.tr (Ali =?ISO-8859-9?Q?Erdin=E7_K=F6ro=F0lu?=)
Date: Wed, 13 Jul 2005 10:51:15 +0300
Subject: Kernel panic in 2.6.11-1.35_FC3@i686
In-Reply-To: <1121213678.4720.7.camel@phantom.wg.xw3.org>
References: <1121213678.4720.7.camel@phantom.wg.xw3.org>
Message-ID: <20050713105115.688c89b4.erdinc@prosoft.com.tr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Wed, 13 Jul 2005 02:14:38 +0200
Johannes Findeisen <mailman at hanez.org> wrote:

> Hello all,
> 
> just got this kernel panic right after updating Fedora core 3 to
> 2.6.11-1.35_FC3. I am running Fedora Core 3 for x86 on an AMD64 machine
> - if this helps?. Since i have no serial console i could not copy and
> paste the panic message, so i have made a photo which you can see at:
> 
> http://hanez.org/images/content/kernelpanic.jpg
> 
> The following package is what i am talking about: 
> 
> kernel-2.6.11-1.35_FC3.i686.rpm
> 
> Please tell me how i could debug such things better in the future. I
> really want to understand the way developers are handling this.

System couldnt mount your rootfs and thats why it gives you kernel panic.
You should check your grub.conf and it should be something like

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title RedHat Enterprise Linux ES 3
        root (hd0,0)
        kernel /vmlinuz-2.4.21-32.EL ro root=/dev/Volume00/LogVol00
        initrd /initrd-2.4.21-32.EL.img
title RedHat Enterprise Linux ES 4
        root (hd0,4)
        kernel /vmlinuz-2.6.9-11.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd (hd0,4)/initrd-2.6.9-11.EL.img
title Fedora Core 4
        root (hd0,8)
        kernel /vmlinuz-2.6.12-1.1390_FC4 ro root=/dev/VolGroup02/LogVol00              
 	initrd (hd0,8)/initrd-2.6.12-1.1390_FC4.img
title Fedora Core 4 - Embedded
        root (hd0,6)
        kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup01/LogVol00
        initrd (hd0,6)/initrd-2.6.11-1.1369_FC4.img

Also be carefull while your are deciding hd0,0 issue cause when you get fdisk /dev/hda or /dev/sda
you gonna see something like

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1        10     80293+  83  Linux
/dev/hda2            11       265   2048287+  8e  Linux LVM
/dev/hda3           266       330    522112+  82  Linux swap
/dev/hda4           331      4870  36467550    5  Extended
/dev/hda5           331       340     80293+  83  Linux
/dev/hda6           341       850   4096543+  8e  Linux LVM
/dev/hda7           851       860     80293+  83  Linux
/dev/hda8           861      1115   2048256   8e  Linux LVM
/dev/hda9          1116      1125     80293+  83  Linux
/dev/hda10         1126      1890   6144831   8e  Linux LVM

hd0,8 means hda(your harddisk) and partition 9 because 0,0 is your boot partition on hda 
On the other hand you should be carefull if you use LVM, VolGroup ID's and LogVol ID's are important. 
In my grub.conf I collect whole kernel images in my hd0,0 partition and just ES 3.0 has a boot loader.

Regards
Ali Erdinc Koroglu
http://www.prosoft.com.tr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC1MfzUZ8xvL9ToPoRArodAJ0Wk8LtLcITswHsNv+9oVCeYwxBywCdHglX
EbyhSpBTpJWxRdrn2IpbRmI=
=mqYQ
-----END PGP SIGNATURE-----



From camilo at mesias.co.uk  Wed Jul 13 09:00:57 2005
From: camilo at mesias.co.uk (Cam)
Date: Wed, 13 Jul 2005 10:00:57 +0100
Subject: No more right click terminal
In-Reply-To: <42D3D00A.8010802@cornell.edu>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D3D00A.8010802@cornell.edu>
Message-ID: <42D4D849.3070000@mesias.co.uk>

Paul A Houle wrote:

>    A general complaint I've had about 'desktop-oriented' Linux 
> distributions is that the GUI tries to push people into half-baked GUI 
> apps and discourage people from opening a terminal window,  which is 
> usually easier to use because there are fewer bugs in the command line 
> programs -- I've got an older machine where my usual way of getting an 
> xterm is Alt-F2 "xterm".

You can run 'bash' or even just 'sh' in a terminal from Alt-F2.

I wonder if it would be possible to upgrade the run command window to 
have a proper shell (complete with command history). Then you could 
switch from the run-command window to a gnome terminal in one GUI step. 
Also the run-command window could have a working directory, and the 
gnome terminals that appear could have a predictable working directory 
(currently they seem to inherit the working directory from a previous 
window).

Which source rpm does the run command dialog come from?

-Cam

-- 
camilo at mesias.co.uk                                                 <--



From dwmw2 at infradead.org  Wed Jul 13 09:07:28 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 13 Jul 2005 10:07:28 +0100
Subject: No more right click terminal
In-Reply-To: <1121143049.3521.16.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
Message-ID: <1121245649.12224.28.camel@localhost.localdomain>

On Mon, 2005-07-11 at 21:37 -0700, Jesse Keating wrote:
> This is yet another move in a long history of Gnome moves that makes me
> wish somebody forked gnome a while ago and removed all these stupid
> 'save the end user from themselves' changes.  For god sakes, make a 'end
> user safe' UI that has all these things in it, and then make a 'real
> user' UI that actually allows work to be done in the way that it has
> been done for years.

I believe we already have it. The two user interfaces of which you speak
are GNOME and KDE.

I'm not actually a KDE user, although I used to be about 8 years ago.
But I suspect I will be again, fairly soon.

-- 
dwmw2



From rodd at clarkson.id.au  Wed Jul 13 09:53:37 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 13 Jul 2005 19:53:37 +1000
Subject: No more right click terminal
In-Reply-To: <1121245649.12224.28.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
Message-ID: <1121248417.16074.19.camel@goose>

On Wed, 2005-07-13 at 10:07 +0100, David Woodhouse wrote:

> I believe we already have it. The two user interfaces of which you speak
> are GNOME and KDE.
> 
> I'm not actually a KDE user, although I used to be about 8 years ago.
> But I suspect I will be again, fairly soon.

Actually, I think David touches on an important point here.  While I
understand why the 'average user' might not need 'developer features' in
the basic gnome interface, and while I understand that these may
actually be confusing for the 'average user' if included, the back lash
from people on these lists (what I would mostly assume to be people
involved in the development process) makes me wonder how Gnome is going
to keep developers interested if they keep making 'development tools'
harder to access?  (What a mouthful).

I'm starting to think that while this move is a worthwhile move, it
needed to be handled a little bit better.  I was the original person to
note that the gnome-terminal had been removed from the menu, and while I
can understand why it is gone, the manner in which it went was a little
unsavory.

I know no that I have alternatives.  I hope that nautilus-gnome-terminal
will make it into core (or at least extras) and I also know that I can
set up gnome-terminal to launch in other ways (keystokes for example,
not my preferred manner after seven years of developing software in
Linux (and using Gnome) but it does work - each to their own).

I guess what got me going was the total lack of 'event a' is going to
happen, but you can achieve the same effect these ways.  Look at the
storm (fire storm maybe - get it? flames?) that's ensued on this list.

Gnome may not wish for the terminal to be included in the base desktop
menu, but I now believe that they need to maintain (and it seems they
are to some degree) packages to reclaim these features.  These packages,
however, need to be in place before removing features so that these sort
of thread-fests occur less and less.

I'm not about to stop using Gnome, but I have wondered about switching
to KDE which I understand has only just recently added this features
(which might say something about what I regard as a feature bloated
desktop).


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From nicolas.mailhot at laposte.net  Wed Jul 13 10:17:58 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 13 Jul 2005 12:17:58 +0200 (CEST)
Subject: No more right click terminal
In-Reply-To: <1121248417.16074.19.camel@goose>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
Message-ID: <55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>


On Mer 13 juillet 2005 11:53, Rodd Clarkson wrote:
> On Wed, 2005-07-13 at 10:07 +0100, David Woodhouse wrote:
>
>> I believe we already have it. The two user interfaces of which you speak
>> are GNOME and KDE.
>>
>> I'm not actually a KDE user, although I used to be about 8 years ago.
>> But I suspect I will be again, fairly soon.
>
> Actually, I think David touches on an important point here.  While I
> understand why the 'average user' might not need 'developer features' in
> the basic gnome interface, and while I understand that these may
> actually be confusing for the 'average user' if included, the back lash
> from people on these lists (what I would mostly assume to be people
> involved in the development process) makes me wonder how Gnome is going
> to keep developers interested if they keep making 'development tools'
> harder to access?  (What a mouthful).

Nowadays Gnome is pretty much a social experiment on how many features you
can remove from old users before they switch and the contributions they
made to the project dry out.

It's interesting to read people claim there is absolutely no problem, user
experience will be enhanced by a simpler desktop, when (for example) at
the same time Gnome browsers sink into obscurity and are replaced by
Firefox.

Seems actual "basic" users would rather cope with the warts of a
non-native app than experience the full Gnome simplicity.

-- 
Nicolas Mailhot



From divij at innomedia.soft.net  Wed Jul 13 10:53:49 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Wed, 13 Jul 2005 16:23:49 +0530
Subject: Asynchronous signal blocking
Message-ID: <1121252029.6757.2.camel@localhost.localdomain>

Hi,
   Can anybody explain me or give me some link regarding how to block
asynchronous signal in a multi-threaded environment in POSIX on Linux.

Thanks 
Divij





From andy at warmcat.com  Wed Jul 13 11:25:12 2005
From: andy at warmcat.com (Andy Green)
Date: Wed, 13 Jul 2005 12:25:12 +0100
Subject: Asynchronous signal blocking
In-Reply-To: <1121252029.6757.2.camel@localhost.localdomain>
References: <1121252029.6757.2.camel@localhost.localdomain>
Message-ID: <42D4FA18.7020707@warmcat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

divij bhatt wrote:

| Hi, Can anybody explain me or give me some link regarding how to
| block asynchronous signal in a multi-threaded environment in POSIX
| on Linux.
|
| Thanks Divij

man signal

has some wisdom on that for you: second sentance of second paragraph.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC1PoXjKeDCxMJCTIRAi3JAJ9ZA5obvT6pwj7rprz5WGl1fTRY9gCfZawg
GxxuozlGy5xS8Y9Hg7FFWkg=
=uDod
-----END PGP SIGNATURE-----



From sundaram at redhat.com  Wed Jul 13 11:31:28 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 13 Jul 2005 17:01:28 +0530
Subject: No more right click terminal
In-Reply-To: <1121248417.16074.19.camel@goose>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
Message-ID: <42D4FB90.4010107@redhat.com>

Hi

>Actually, I think David touches on an important point here.  While I
>understand why the 'average user' might not need 'developer features' in
>the basic gnome interface, and while I understand that these may
>actually be confusing for the 'average user' if included, the back lash
>from people on these lists (what I would mostly assume to be people
>involved in the development process) makes me wonder how Gnome is going
>to keep developers interested if they keep making 'development tools'
>harder to access?  (What a mouthful).
>
>  
>
Developers are designing it for end users. Not for themselves


>I guess what got me going was the total lack of 'event a' is going to
>happen, but you can achieve the same effect these ways.  Look at the
>storm (fire storm maybe - get it? flames?) that's ensued on this list.
>  
>
Completely useless

regards
Rahul



From buildsys at redhat.com  Wed Jul 13 11:49:06 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 13 Jul 2005 07:49:06 -0400
Subject: rawhide report: 20050713 changes
Message-ID: <200507131149.j6DBn6SL022760@porkchop.devel.redhat.com>

 

 
Updated Packages:

audit-0.9.17-1
--------------
* Tue Jul 12 2005 Steve Grubb <sgrubb at redhat.com> 0.9.17-1
- Fix ausearch buffers to hold long filenames
- Make a0 long long for 64 bit kernels & 32 bit ausearch.

bind-24:9.3.1-7
---------------
* Tue Jul 12 2005 Jason Vas Dias <jvdias at redhat.com> - 24:9.3.1-7
- fix bug 160914: resolver utilities should try next server on empty referral
                  (now that glibc bug 162625 is fixed)
		  host and nslookup now by default try next server on SERVFAIL
		  (host now has '-s' option to disable, and nslookup given
                   '[no]fail' option similar to dig's [no]fail option).
- rebuild and re-test with new glibc & gcc (all tests passed).

* Tue May 31 2005 Jason Vas Dias <jvdias at redhat.com> - 24:9.3.1-6
- fix bug 157950: dig / host / nslookup should reject invalid resolv.conf
                  files and not use uninitialized garbage nameserver values
                  (ISC bug 14841 raised).

* Mon May 23 2005 Jason Vas Dias <jvdias at redhat.com> - 24:9.3.1-4_FC4
- Fix SDB LDAP

dasher-3.2.15-2
---------------
* Tue Jul 12 2005 <mclasen at redhat.com> 3.2.15-2
- Rebuild

ghostscript-8.15-0.rc3.4
------------------------
* Tue Jul 12 2005 Tim Waugh <twaugh at redhat.com> 8.15-0.rc3.4
- Add Japanese fonts to FAPIcidfmap (bug #161187).
- Moved Resource directory.
- Added use-external-freetype patch (bug #161187).

* Mon Jul 11 2005 Tim Waugh <twaugh at redhat.com>
- Build requires libtiff-devel (bug #162826).

gnome-applets-1:2.11.1-2
------------------------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> 1:2.11.1-2
- Rebuilt

gnome-media-2.11.4-1
--------------------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> 2.11.4-1
- Newer upstream version

gnome-panel-2.11.4-2
--------------------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> 2.11.4-2
- Rebuild

gnome-system-monitor-2.11.4-1
-----------------------------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> 2.11.4-1
- Newer upstream version

gok-1.0.5-2
-----------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> 1.0.5-2
- Rebuilt

hal-0.5.3-2
-----------
* Tue Jul 12 2005 David Zeuthen <davidz at redhat.com> 0.5.3-2
- Fix a minor packaging bug

* Tue Jul 12 2005 David Zeuthen <davidz at redhat.com> 0.5.3-1
- Update to upstream release 0.5.3
- Drop patches as they are upstream

kernel-2.6.12-1.1432_FC5
------------------------
* Wed Jul 13 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3

* Tue Jul 12 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc2-git5
- Fix IDE locking bug de jour.
- Workaround a usbmon deficiency.
- Re-add Tux again.

krb5-1.4.1-6
------------
* Wed Jun 29 2005 Nalin Dahyabhai <nalin at redhat.com> 1.4.1-6
- rebuild

* Wed Jun 29 2005 Nalin Dahyabhai <nalin at redhat.com> 1.4.1-5
- fix telnet client environment variable disclosure the same way NetKit's
  telnet client did (CAN-2005-0488) (#159305)
- keep apps which call krb5_principal_compare() or krb5_realm_compare() with
  malformed or NULL principal structures from crashing outright (Thomas Biege)
  (#161475)

* Tue Jun 28 2005 Nalin Dahyabhai <nalin at redhat.com>
- apply fixes from draft of MIT-KRB5-SA-2005-002 (CAN-2005-1174,CAN-2005-1175)
  (#157104)
- apply fixes from draft of MIT-KRB5-SA-2005-003 (CAN-2005-1689) (#159755)

libgnomeprintui22-2.11.0-1
--------------------------
* Mon Jul 11 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.0-1
- Newer upstream version

libgtop2-2.11.1-1
-----------------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.1-1
- Update to newer upstream version

metacity-2.11.0-1
-----------------
* Wed Jul 13 2005 Matthias Clasen <mclasen at redhat.com> 2.11.0-1
- newer upstream version

mysql-4.1.12-2
--------------
* Tue Jul 12 2005 Tom Lane <tgl at redhat.com> 4.1.12-2
- Fix buffer overflow newly exposed in isam code; it's the same issue
  previously found in myisam, and not very exciting, but I'm tired of
  seeing build warnings.

* Mon Jul 11 2005 Tom Lane <tgl at redhat.com> 4.1.12-1
- Update to MySQL 4.1.12 (includes a fix for bz#158688, bz#158689)
- Extend mysql-test-ssl.patch to solve rpl_openssl test failure (bz#155850)
- Update mysql-lock-ssl.patch to match the upstream committed version
- Add --with-isam to re-enable the old ISAM table type, per bz#159262
- Add dependency on openssl-devel per bz#159569
- Remove manual.txt, as upstream decided not to ship it anymore;
  it was redundant with the mysql.info file anyway.

* Mon May 09 2005 Tom Lane <tgl at redhat.com> 4.1.11-4
- Include proper locking for OpenSSL in the server, per bz#155850

net-snmp-5.2.1.2-1
------------------
* Wed Jul 13 2005 Radek Vokal <rvokal at redhat.com> - 5.2.1.2-1
- CAN-2005-2177 new upstream version fixing DoS (#162908)

openoffice.org-1:1.9.116-3.2.0.fc5
----------------------------------
* Mon Jul 11 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.116-3
- enable evo addressbook in addressbook wizard
- rh#162875# extra leading / from file picker
- update fpicker stuff
- add workspace.impress63.patch for rh#162158#
- add openoffice.org-1.9.116.rh162935.gccXXXXX.weirdcrash.patch as a temporary
  workaround until I figure out just what the hell is wrong

* Mon Jul 11 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.116-2
- add openoffice.org-1.9.116.ooo51774.rsc.parallel.patch

selinux-policy-strict-1.25.2-1
------------------------------
* Tue Jul 12 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-1
- Update to latest from NSA

* Mon Jul 11 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-10
- Change file context for iiimd -> iiimd.bin

selinux-policy-targeted-1.25.2-1
--------------------------------
* Tue Jul 12 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-1
- Update to latest from NSA

* Mon Jul 11 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-10
- Change file context for iiimd -> iiimd.bin

sound-juicer-2.11.3-1
---------------------
* Tue Jul 12 2005 Matthias Clasen <mclasen at redhat.com> 2.11.3-1
- Newer upstream version

stunnel-4.11-1
--------------
* Tue Jul 12 2005 Miloslav Trmac <mitr at redhat.com> - 4.11-1
- Update to stunnel-4.11
- Fix int/size_t mismatches in stack_info ()
- Update Certificate-Creation for /etc/pki

system-config-printer-0.6.136-1
-------------------------------
* Tue Jul 12 2005 Tim Waugh <twaugh at redhat.com> 0.6.136-1
- 0.6.136:
  - Cope with DB inconsistencies (bug #162033).
  - Don't display "hp:/no_device_found" HPLIP device.

usermode-1.80-2
---------------
* Tue Jul 12 2005 Jindrich Novy <jnovy at redhat.com> 1.80-2
- rebuild because of broken libwnck dependency

valgrind-1:2.4.0-3
------------------
* Tue Jul 12 2005 Jakub Jelinek <jakub at redhat.com> 2.4.0-3
- build some insn tests with -mmmx, -msse or -msse2 (#161572)
- handle glibc-2.3.90 the same way as 2.3.[0-5]

* Wed Mar 30 2005 Jakub Jelinek <jakub at redhat.com> 2.4.0-2
- resurrect the non-upstreamed part of valgrind_h patch
- remove 2.1.2-4G patch, seems to be upstreamed
- resurrect passing -fno-builtin in memcheck tests

* Sun Mar 27 2005 Colin Walters <walters at redhat.com> 2.4.0-1
- New upstream version 
- Update valgrind-2.2.0-regtest.patch to 2.4.0; required minor
  massaging
- Disable valgrind-2.1.2-4G.patch for now; Not going to touch this,
  and Fedora does not ship 4G kernel by default anymore
- Remove upstreamed valgrind-2.2.0.ioctls.patch
- Remove obsolete valgrind-2.2.0-warnings.patch; Code is no longer
  present
- Remove upstreamed valgrind-2.2.0-valgrind_h.patch
- Remove obsolete valgrind-2.2.0-unnest.patch and
  valgrind-2.0.0-pthread-stacksize.patch; valgrind no longer
  includes its own pthread library

vim-1:6.3.080-1
---------------
* Sun Jun 12 2005 Karsten Hopp <karsten at redhat.de> 6.3.080-1
- update to patchlevel 80

xorg-x11-6.8.2-43
-----------------
* Tue Jul 12 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-43
- Added xorg-x11-6.8.2-xnest-update-modifier-state-fdo3030-fdo3664.patch and
  xorg-x11-6.8.2-xnest-fix-warning-spew-fdo3513.patch to fix Xnest bugs
  referenced in bug (#162246)
- Updated xorg-x11-6.8.2-redhat-nv-disable-s2scopy-on-geforce-6x00.patch to
  add a log file message about ScreenToScreenCopy being disabled on some
  GeForce models for bug (#157715)
- Added xorg-x11-6.8.2-libvgahw-workaround-rh161242.patch to attempt to work
  around bug (#161242, 162274, 153729, 159106, 160500, 161047, 160470,
  160453, 160307, 160777, 151688, 154502, 161566, 160950, 160580, 157556,
  161756, 160477, 155416, 160287, 162567, 157593, fdo#2991, fdo#2976,
  fdo#3557, gnu#22278)

Broken deps for s390
----------------------------------------------------------
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	dhcp - 10:3.0.2-14.FC5.s390 requires kernel >= 0:2.2.18
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390 requires gjdoc
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	selinux-policy-strict-sources - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	selinux-policy-strict - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted-sources - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for i386
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ia64 requires gjdoc
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	rgmanager - 1.9.31-3.ia64 requires ccs
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)



Broken deps for s390x
----------------------------------------------------------
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	selinux-policy-strict - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted-sources - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.s390x requires gjdoc
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	selinux-policy-targeted - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-strict-sources - 1.25.2-1.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	dhcp - 10:3.0.2-14.FC5.s390x requires kernel >= 0:2.2.18
	p6spy - 1.3-2jpp_1fc.noarch requires regexp



Broken deps for x86_64
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	firstboot - 1.3.43-1.noarch requires system-config-display
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_36rh.ppc64 requires gjdoc
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)





From perbj at stanford.edu  Wed Jul 13 16:39:55 2005
From: perbj at stanford.edu (Per Bjornsson)
Date: Wed, 13 Jul 2005 09:39:55 -0700
Subject: No more right click terminal
In-Reply-To: <55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
Message-ID: <1121272795.13335.18.camel@localhost.localdomain>

On Wed, 2005-07-13 at 12:17 +0200, Nicolas Mailhot wrote:

> It's interesting to read people claim there is absolutely no problem, user
> experience will be enhanced by a simpler desktop, when (for example) at
> the same time Gnome browsers sink into obscurity and are replaced by
> Firefox.
> 
> Seems actual "basic" users would rather cope with the warts of a
> non-native app than experience the full Gnome simplicity.

I think that this is about the worst example you could possibly have
chosen to go with. Firefox was explicitly designed with goals very much
in line with the Gnome desktop: Creating a browser with a simple
interface for regular users. In the Mozilla community, well not so much
in the core developer community as far as I can tell but in the
hangaround crowd, moving from the monolithic Mozilla Suite to the
individual apps with their simplified interfaces has also caused a lot
of uproar. Yet I'd say that Firefox qualifies as a much greater success
than the Moz Suite ever was, finding both fame and huge amounts of
users.

Epiphany was always rather obscure (at least in terms of user base), and
with Firefox crowding the market for a simple-UI browser with way
superior marketing, Epiphany is really in a tight spot. That really says
nothing about Gnome as a whole.

Now, the Firefox comparison is interesting in one way though: Firefox
draws people with some development skills somewhat into the community by
means of the extension mechanism: you can code up cool add-ons easily.
In some sense, the removal of the "Open terminal..." feature, replaced
by the nautilus-open-terminal Nautilus extension, actually maps
perfectly onto the Firefox idea of a simple core which "power users" can
extend with some extension mechanism.

Perhaps the trick for Gnome is to market the various extension
possibilities more. Clearly fun stuff is possible (Nautilus extensions,
look at Brightside and Devilspie for WM crack...) In fact I think that
this to a great extent is actually a marketing problem rather than a
technical problem. But marketing is serious stuff, so a marketing
problem is certainly a real problem, not something to handwave away...

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From walters at redhat.com  Wed Jul 13 17:00:56 2005
From: walters at redhat.com (Colin Walters)
Date: Wed, 13 Jul 2005 13:00:56 -0400
Subject: No more right click terminal
In-Reply-To: <1121248417.16074.19.camel@goose>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
Message-ID: <1121274056.10565.15.camel@nexus.verbum.private>

On Wed, 2005-07-13 at 19:53 +1000, Rodd Clarkson wrote:

> Actually, I think David touches on an important point here.  While I
> understand why the 'average user' might not need 'developer features' in
> the basic gnome interface, and while I understand that these may
> actually be confusing for the 'average user' if included, the back lash
> from people on these lists (what I would mostly assume to be people
> involved in the development process) makes me wonder how Gnome is going
> to keep developers interested if they keep making 'development tools'
> harder to access?  (What a mouthful).

It's not about making them harder to access; it's simply removing things
that are only useful for developers and system administrators from the
core desktop.  Historically a large part of GNOME's audience was
developers and system administrators, because that was the vast majority
of the Linux user audience, but the point is we want to change that.

Think of it this way: what if GNOME's historical audience had been
musicians?  Then the right click menu might have had 
"Open Musical Score Composer".  Having that makes as much sense to the
general population as "Open Terminal" does.

As Bryan, Per, and others said though, we *do* want to make it easy for
power users/developers to tweak extend and their desktop:
http://live.gnome.org/PowerUserTools

Someone should just package nautilus-open-terminal, which AFAICS should
address the vast majority of complaints in this thread.

With respect to the interface changing; that's true, but it seems to me
that the GNOME/Fedora interface has been changing substantially in other
ways (e.g. panel revamp from FC2->FC3) that the "Open Terminal" is just
a relatively small part of it.





From Nicolas.Mailhot at laPoste.net  Wed Jul 13 19:27:47 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 13 Jul 2005 21:27:47 +0200
Subject: No more right click terminal
In-Reply-To: <1121272795.13335.18.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
Message-ID: <1121282867.21244.27.camel@rousalka.dyndns.org>

Le mercredi 13 juillet 2005 ? 09:39 -0700, Per Bjornsson a ?crit :
> On Wed, 2005-07-13 at 12:17 +0200, Nicolas Mailhot wrote:
> 
> > It's interesting to read people claim there is absolutely no problem, user
> > experience will be enhanced by a simpler desktop, when (for example) at
> > the same time Gnome browsers sink into obscurity and are replaced by
> > Firefox.
> > 
> > Seems actual "basic" users would rather cope with the warts of a
> > non-native app than experience the full Gnome simplicity.
> 
> I think that this is about the worst example you could possibly have
> chosen to go with.

Not at all.
For Mozilla people Firefox is simple.
But compared to Galeon or Epiphany - it's a very complex UI.
In fact if Gnome people took over Firefox today they'd be busily
removing scores of features.

I could have taken the office case as example but it wouldn't have been
fair. Galeon and Epy OTOH had several years of head start over Firefox
for building the perfect simple UI, the advantage of being native and
integrating with the desktop, insider access to distributions, and still
managed to botch it because of the very same attitude that's discussed
in this thread.

It's good to have a grand top-down vision, but userbase should not be
ignored. Especially not because it does not conform to some sort of
hypothetical perfect target user (hint : populations are not composed
uniformly of synthetic median users). I've been in a start-up and any
user feedback (even unrepresentative user feedback) is better than the
models people have in their heads. Teams that do not accept it do not
get past their first birthday.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050713/cddf83b0/attachment.sig>

From davide.rossetti at roma1.infn.it  Wed Jul 13 19:43:51 2005
From: davide.rossetti at roma1.infn.it (Davide Rossetti)
Date: Wed, 13 Jul 2005 21:43:51 +0200
Subject: nptl and signals
In-Reply-To: <1121151920.8255.35.camel@localhost.localdomain>
References: <1121151920.8255.35.camel@localhost.localdomain>
Message-ID: <42D56EF7.9040608@roma1.infn.it>

divij bhatt wrote:

>Hi,
>   I have problem regarding nptl in multi-threading environment.I am
>creating three threads and each thread is calling a functions in which I
>am setting the time for each thread using setitimer.On expiration of
>that timer SIGALRM is called which calls a signal handler function in
>which I am setting the flag and when control return to the main program
>I am checking that flag if it is one then I am sending the packet and
>again make that flag 0.I am using thread specific data and use set
>specific and getspecific to read the threads data.
>But the problem is that in signal handler instead of 3 there are 4
>threads running(4th one suppose to be main thread) which disturbs the
>timing of other threads.Which results in to the packet drooping.Also the
>control is not returning to the main program So kindly help me out,I am
>also attaching the copy of source code.
>
>Thanks in Advance
>Divij
>
>  
>
>------------------------------------------------------------------------
>
>#include<pthread.h>
>#include<stdio.h>
>#include<sys/types.h>
>#include<sys/socket.h>
>#include<netdb.h>
>#include<string.h>
>#include<arpa/inet.h>
>#include<unistd.h>
>#include<sys/times.h>
>#include<semaphore.h>
>#include<sys/time.h>
>#include<signal.h>
>#define CNTR 3 
>
>int sd,rc,i=0,sockfd,len,which=ITIMER_REAL,mark=0;
>struct sockaddr_in cliaddr,remoteservaddr;
>struct hostent *h;
>time_t timeval;
>struct itimerval value;
>struct timespec ts;
>struct timeval tz;
>struct sigaction act;
>FILE *fp;
>char ch,buffer[1000];
>volatile sig_atomic_t flag[CNTR]={0},k=0;
>int n,j,z=0,t,track=0;
>
>static pthread_key_t key;
>pthread_t tid[CNTR];
>pthread_attr_t attr;
>pthread_mutex_t mylock;
>long int thid[3];
>
>
>void myflag(int sig) //This is a signal handler
>{
>    int s=0,ret;
>    pthread_mutex_lock(&mylock);
>    int k =(int)pthread_getspecific(key);
>    printf("\nIn signal Value of K:%d and thread id is:%lu\n",k,pthread_self());   
>    switch(k)
>    {
>      case 0: printf("I am the main thread\t \n");
>              break;
>      
>      case 1:
>              flag[k-1] = 1;
>              break;
>      case 2:
>              flag[k-1] = 1;
>              break;
>     
>      case 3:
>              flag[k-1] = 1;
>              break;
>   
>   }
>   pthread_mutex_unlock(&mylock);
>   return;
>}
>  
>
I did not read past this... but mutex functions are not documented as 
signal safe, are they ?
in fact, the man for pthread_mutex_lock says:
      "If a signal is delivered to a thread waiting for a mutex, upon 
return from the signal handler the thread shall
       resume waiting for the mutex as if it was not interrupted."

i.e. sem_post() is explicitly documented as sig safe in the man page:
       "The  sem_post()  function shall be reentrant with respect to 
signals and may be invoked from a signal-catching
       function."

moreover, in nptl I think that signals are not per-thread but 
per-process... so there is no hope that a signal is routed to a specific 
thread. instead, you assume that the signal is routed to the thread 
which called setitimer().

reading more, in general I think your implementation is "weak" at least :)

regards



From davide.rossetti at roma1.infn.it  Wed Jul 13 19:51:51 2005
From: davide.rossetti at roma1.infn.it (Davide Rossetti)
Date: Wed, 13 Jul 2005 21:51:51 +0200
Subject: Asynchronous signal blocking
In-Reply-To: <1121252029.6757.2.camel@localhost.localdomain>
References: <1121252029.6757.2.camel@localhost.localdomain>
Message-ID: <42D570D7.70009@roma1.infn.it>

divij bhatt wrote:

>Hi,
>   Can anybody explain me or give me some link regarding how to block
>asynchronous signal in a multi-threaded environment in POSIX on Linux.
>
>Thanks 
>Divij
>  
>
pthread_sigmask() ?



From shahms at shahms.com  Wed Jul 13 20:06:18 2005
From: shahms at shahms.com (Shahms King)
Date: Wed, 13 Jul 2005 13:06:18 -0700
Subject: No more right click terminal
In-Reply-To: <1121282867.21244.27.camel@rousalka.dyndns.org>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
Message-ID: <42D5743A.6010300@shahms.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Mailhot wrote:
| Le mercredi 13 juillet 2005 ? 09:39 -0700, Per Bjornsson a ?crit :
|
|>On Wed, 2005-07-13 at 12:17 +0200, Nicolas Mailhot wrote:
|>
|>
|>>It's interesting to read people claim there is absolutely no problem,
user
|>>experience will be enhanced by a simpler desktop, when (for example) at
|>>the same time Gnome browsers sink into obscurity and are replaced by
|>>Firefox.
|>>
|>>Seems actual "basic" users would rather cope with the warts of a
|>>non-native app than experience the full Gnome simplicity.
|>
|>I think that this is about the worst example you could possibly have
|>chosen to go with.
|
|
| Not at all.
| For Mozilla people Firefox is simple.
| But compared to Galeon or Epiphany - it's a very complex UI.
| In fact if Gnome people took over Firefox today they'd be busily
| removing scores of features.

Compared to Epiphany, perhaps, but certainly not Galeon.  Epiphany's
goal was to make a simple UI, Galeon's was to cram everything under the
sun into a GNOME interface.

For a little history:

Firefox is to Mozilla what
Epiphany is to Galeon.

Both Epiphany and Galeon lost their relevancy when Firefox and Mozilla
started integrating into the GNOME desktop.  There are still some warts,
but most stuff just works.  Firefox is now and always has been "Mozilla
simplified".  They took out UI for a lot of things, relegated more
things to extensions and just plain removed features from Mozilla.  The
funny thing is, more people use Firefox than Mozilla these days
"despite" its simplified UI.

In fact, apart from the many Firefox extensions I have installed, the
Firefox and Epiphany UIs are almost identical in terms of layout and
functionality.  Your argument is specious at best and your analogy
faulty.  If you don't like the general trend of simplifying the user
interface, that's one thing, but it's definitely not a GNOME-only trend
and certainly isn't going to stop.

- --
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC1XQ6/qs2NkWy11sRAhZxAJ9kJaekxAQoGBcOPLjr2vesryY4cACdFbnq
0qZ2LuPkZEQdxCKaE1MrOfc=
=SQch
-----END PGP SIGNATURE-----



From mailman at hanez.org  Wed Jul 13 20:25:29 2005
From: mailman at hanez.org (Johannes Findeisen)
Date: Wed, 13 Jul 2005 22:25:29 +0200
Subject: Kernel panic in 2.6.11-1.35_FC3@i686
In-Reply-To: <20050713105115.688c89b4.erdinc@prosoft.com.tr>
References: <1121213678.4720.7.camel@phantom.wg.xw3.org>
	<20050713105115.688c89b4.erdinc@prosoft.com.tr>
Message-ID: <1121286329.4290.21.camel@phantom.wg.xw3.org>

On Wed, 2005-07-13 at 10:51 +0300, Ali Erdin? K?ro?lu wrote:
> System couldnt mount your rootfs and thats why it gives you kernel panic.
> You should check your grub.conf and it should be something like
> 
> default=0
> timeout=10
> splashimage=(hd0,0)/grub/splash.xpm.gz
> title RedHat Enterprise Linux ES 3
>         root (hd0,0)
>         kernel /vmlinuz-2.4.21-32.EL ro root=/dev/Volume00/LogVol00
>         initrd /initrd-2.4.21-32.EL.img
> title RedHat Enterprise Linux ES 4
>         root (hd0,4)
>         kernel /vmlinuz-2.6.9-11.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet
>         initrd (hd0,4)/initrd-2.6.9-11.EL.img
> title Fedora Core 4
>         root (hd0,8)
>         kernel /vmlinuz-2.6.12-1.1390_FC4 ro root=/dev/VolGroup02/LogVol00              
>  	initrd (hd0,8)/initrd-2.6.12-1.1390_FC4.img
> title Fedora Core 4 - Embedded
>         root (hd0,6)
>         kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup01/LogVol00
>         initrd (hd0,6)/initrd-2.6.11-1.1369_FC4.img
> 
> Also be carefull while your are deciding hd0,0 issue cause when you get fdisk /dev/hda or /dev/sda
> you gonna see something like
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1        10     80293+  83  Linux
> /dev/hda2            11       265   2048287+  8e  Linux LVM
> /dev/hda3           266       330    522112+  82  Linux swap
> /dev/hda4           331      4870  36467550    5  Extended
> /dev/hda5           331       340     80293+  83  Linux
> /dev/hda6           341       850   4096543+  8e  Linux LVM
> /dev/hda7           851       860     80293+  83  Linux
> /dev/hda8           861      1115   2048256   8e  Linux LVM
> /dev/hda9          1116      1125     80293+  83  Linux
> /dev/hda10         1126      1890   6144831   8e  Linux LVM
> 
> hd0,8 means hda(your harddisk) and partition 9 because 0,0 is your boot partition on hda 
> On the other hand you should be carefull if you use LVM, VolGroup ID's and LogVol ID's are important. 
> In my grub.conf I collect whole kernel images in my hd0,0 partition and just ES 3.0 has a boot loader.

Hello, thanks for reply but it didn't helped me out. I am using Linux
since 6 years and i have some _little_ knowledge... ;-)

I don't use LVM because i never had a need for it. The entry in my
grub.conf looks exctly like the entry for an older kernel which still is
installed and i am using right now.

I will give Dan Fruehauf's hint a try...

Anyway, thanks a lot!

--
Johannes Findeisen 



From Nicolas.Mailhot at laPoste.net  Wed Jul 13 20:48:04 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 13 Jul 2005 22:48:04 +0200
Subject: No more right click terminal
In-Reply-To: <42D5743A.6010300@shahms.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
Message-ID: <1121287685.28486.18.camel@rousalka.dyndns.org>

Le mercredi 13 juillet 2005 ? 13:06 -0700, Shahms King a ?crit :
> Your argument is specious at best and your analogy
> faulty.  If you don't like the general trend of simplifying the user
> interface, that's one thing, but it's definitely not a GNOME-only trend
> and certainly isn't going to stop.

The problem is that a lot of it is not simplifying because there's a
problem but simplifying for the sake of simplifying.

What's specious the way all those changes are never backed by real user
studies but by "we think best" and "you're not the user we want"
arguments. I (and probably others) would not mind it as much if
simplifier proponents spent their energy explaining with real use-cases
why their changes are good instead of devoting their energies to
convince their users they are retards that can not understand what's
good for them.

"Simplicity" by itself is not an argument. Just like "Europe" is a bit
short if you want to pass several hundred binding law articles.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050713/a5cb0fab/attachment.sig>

From jspaleta at gmail.com  Wed Jul 13 21:41:13 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 13 Jul 2005 17:41:13 -0400
Subject: No more right click terminal
In-Reply-To: <1121287685.28486.18.camel@rousalka.dyndns.org>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
Message-ID: <604aa79105071314411dc3a1ac@mail.gmail.com>

On 7/13/05, Nicolas Mailhot <Nicolas.Mailhot at laposte.net> wrote:
> What's specious the way all those changes are never backed by real user
> studies but by "we think best"

Are you willing to spend your time and money to conduct credible
studies?  I think you are being a wee bit unreasonable to expect that
every feature change must come with its own impact study.  I'm sure
the gnome usability team would absolutely love to see someone who
could dedicate every waking moment of their time surveying "real"
people to see how proposed changes impacted "real" workloads. I'd love
a pony, I'm sure the gnome usability team would love a workhorse,
especially one they didn't have to pay.

In broader strokes... I think gnome IS following lessons taken from
existing credible studies as they become available. I think Sun's 2001
study marked a turning point towards a general change to designing for
target users instead of designing for existing developers...and I've
seen no credible study offered anywhere that suggests gnome's changes
through the whole gnome 2 era are having a negative impact on the
target audience... and nothing but ancedotal grumbling from the
technical elite.  You and I live in the 0.1% of the tail when it comes
to technical literacy.. our personal likes and dislikes weight not
heavily on the mean nor the median.

But if you are really interested in producing unbiased data.. I
suggest you follow the methodology laid out in the latest Novell
study,  purchase your own portable usability lab for $2K and hit the
shopping malls collecting data from normal people.  I suggest you get
in touch with the gnome usability team and co-ordinate your efforts
before you start hitting the street with your usability lab.

http://developer.gnome.org/projects/gup/usertesting.html


-jef"
3.3 nano-farad capacitor... 5 cents,
5 kilo-ohm resistor ... 10 cents, 
watching  megajoules of stored energy discharge through the outside of
your equipment cabinet, vaporize the ground strap and then arc through
the air burning a residual image into your retinas for the next 3
hours because your charging relay circuit did something very odd...
priceless
"spaleta



From alan at redhat.com  Wed Jul 13 21:54:47 2005
From: alan at redhat.com (Alan Cox)
Date: Wed, 13 Jul 2005 17:54:47 -0400
Subject: No more right click terminal
In-Reply-To: <604aa79105071314411dc3a1ac@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
Message-ID: <20050713215447.GB18044@devserv.devel.redhat.com>

On Wed, Jul 13, 2005 at 05:41:13PM -0400, Jeff Spaleta wrote:
> a pony, I'm sure the gnome usability team would love a workhorse,
> especially one they didn't have to pay.

People have been studying it and quite hard. There is a big difference in
most technologies between the real techies, the early adopters and the majority

They want different things, they behave in different ways and they have very
different priorities. Borrow a copy of "Inside the tornado" (Moore, G. 1995)
and read about "crossing the chasm"

> shopping malls collecting data from normal people.  I suggest you get
> in touch with the gnome usability team and co-ordinate your efforts
> before you start hitting the street with your usability lab.

That assumes the people your product must appeal to are those who use it, and
them alone, its not usually so simple



From jkeating at j2solutions.net  Wed Jul 13 22:42:39 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 13 Jul 2005 15:42:39 -0700
Subject: No more right click terminal
In-Reply-To: <1121274056.10565.15.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
Message-ID: <1121294559.31376.56.camel@prometheus.gamehouse.com>

On Wed, 2005-07-13 at 13:00 -0400, Colin Walters wrote:
> As Bryan, Per, and others said though, we *do* want to make it easy for
> power users/developers to tweak extend and their desktop:
> http://live.gnome.org/PowerUserTools

This we appreciate.

> Someone should just package nautilus-open-terminal, which AFAICS should
> address the vast majority of complaints in this thread.

If nobody gets to it by the time I"m done w/ my book editing, I'll look
at it.

> With respect to the interface changing; that's true, but it seems to me
> that the GNOME/Fedora interface has been changing substantially in other
> ways (e.g. panel revamp from FC2->FC3) that the "Open Terminal" is just
> a relatively small part of it.
> 

small part, or straw that breaks the camel's back?

-- 
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



From fedora-devel at tlarson.com  Wed Jul 13 23:27:09 2005
From: fedora-devel at tlarson.com (Tyler Larson)
Date: Wed, 13 Jul 2005 17:27:09 -0600
Subject: No more right click terminal
In-Reply-To: <1121287685.28486.18.camel@rousalka.dyndns.org>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
Message-ID: <42D5A34D.5060307@tlarson.com>

Nicolas Mailhot wrote:
> What's specious the way all those changes are never backed by real user
> studies but by "we think best" and "you're not the user we want"
> arguments. I (and probably others) would not mind it as much if
> simplifier proponents spent their energy explaining with real use-cases
> why their changes are good instead of devoting their energies to
> convince their users they are retards that can not understand what's
> good for them.
> 

You hit it on the nose right there. GNOME's past behavior has earned them the 
extreme distrust of a very large portion of their users. As such, any move 
that further inconveniences the already alienated userbase is met with a 
knee-jerk reaction of outrage. It's not just the changes they made; it's the 
perceived "shut up, you're stupid" response that the users felt they were met 
with when they disagreed.

Many of the decisions that come into question fall into a particular category. 
There's two major reasons why an interface might be easy to use: It can be 
naturally intuitive, or it can be what you're used to. I could build a clock 
where the hands rotate counter-clockwise, and my design may truly even be more 
naturally intuitive than the norm. But users will still find it confusing 
because they're so used to something that's different.

GNOME's more controversial decisions have been similar to, say, using the 
Dvorak keyboard layout by default. You can cite all sorts of studies about how 
it's faster and decreases the probability of a repetitive stress injury. You 
can even say that QWERTY is still available for the minority who want to use 
it. And besides, people who use QWERTY keyboards aren't the target audience 
anyway.

The fact remains that sometimes, the "better option" isn't the best decision. 
It's a judgment call--there's often good reasoning for either side. But what 
frustrates the user is the illogically uncompromising fervor with which the 
developers defend their position. It's very... RMS.

I personally think that removing the terminal from the context menu is the 
correct thing to do (it should have stayed on the panel with the other 
launchers--and it sure as hell better go back). Still, my initial reaction was 
mild outrage--it felt like yet another personal attack against me. Another 
"you don't belong here" message from GNOME. I certainly understand why others 
were angry.



From stickster at gmail.com  Thu Jul 14 00:17:06 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 13 Jul 2005 20:17:06 -0400
Subject: No more right click terminal
In-Reply-To: <1121294559.31376.56.camel@prometheus.gamehouse.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<1121294559.31376.56.camel@prometheus.gamehouse.com>
Message-ID: <1121300226.3826.31.camel@localhost.localdomain>

On Wed, 2005-07-13 at 15:42 -0700, Jesse Keating wrote:
> On Wed, 2005-07-13 at 13:00 -0400, Colin Walters wrote:
> > Someone should just package nautilus-open-terminal, which AFAICS should
> > address the vast majority of complaints in this thread.
> 
> If nobody gets to it by the time I"m done w/ my book editing, I'll look
> at it.

I hesitate to speak up in the presence of people far more experienced
than I, but I did a quick one that anyone is free to criticize, steal,
and/or adopt.

http://rpm.frields.org/FC5/nautilus-open-terminal/

Please be gentle, I'm just a doc writer.  :-D

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050713/a068c9bf/attachment.sig>

From kaboom at oobleck.net  Thu Jul 14 04:06:45 2005
From: kaboom at oobleck.net (Chris Ricker)
Date: Thu, 14 Jul 2005 00:06:45 -0400 (EDT)
Subject: No more right click terminal
In-Reply-To: <1121272795.13335.18.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.63.0507131238380.10535@urd.oobleck.net>

On Wed, 13 Jul 2005, Per Bjornsson wrote:

> Perhaps the trick for Gnome is to market the various extension
> possibilities more. Clearly fun stuff is possible (Nautilus extensions,
> look at Brightside and Devilspie for WM crack...) In fact I think that
> this to a great extent is actually a marketing problem rather than a
> technical problem. But marketing is serious stuff, so a marketing
> problem is certainly a real problem, not something to handwave away...

That reminds me, I packaged Devil's Pie a while ago but hadn't asked for a 
review for inclusion in FE yet

<http://www.oobleck.net/kaboom/fedora/srpms/devilspie-0.8-1.src.rpm>

I know there's a newer release out for Gnome 2.10 -- I'll update the 
package to that in a day or two when I do more packaging stuff....

later,
chris



From notting at redhat.com  Thu Jul 14 04:12:13 2005
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 14 Jul 2005 00:12:13 -0400
Subject: PCMCIA & udev changes
Message-ID: <20050714041213.GA905@nostromo.devel.redhat.com>

Beginning tomorrow, the following changes will be in rawhide:

- pcmcia-cs will be replaced with the new pcmciautils

- udev will be upgraded to 062

What does this mean for you, the user?

- PCMCIA support should be better. Notably, 16-bit PCMCIA support will be
  going through the same hotplug, etc. mechanisms as Cardbus, PCI, and other
  devices.

- Certain operations should be faster. The new udev internalizes some of
  the mechanisms that were farmed out to scripts before (such as
  loading of modules for PCI, PCMCIA/Cardbus, and USB), so things should
  be faster.

What does this mean for you, the developer?

- The use of /etc/hotplug.d and /etc/dev.d for the running of programs on
  hotplug and udev events is officially deprecated.
  
  All programs that have been run in this way need to be converted to
  RUN targets in udev rule files; these can be dropped in /etc/udev/rules.d.
  Old dev.d and hotplug.d events will still be run in a compatibility mode
  for now... I'm not yet sure how long we will continue to do so.

What sort of problems could arise, and where should they be filed?

- All matching of of PCMCIA devices to drivers is done via standard module
  aliases. /etc/pcmcia/config is no longer used.
  
  If your driver isn't loaded properly, bugs should be filed against 'kernel';
  ids will need to be added to the drivers.

- Not everything may be converted to new udev rules yet. For things that aren't,
  please file bugs against the relevant packages.

And, of course, there could be something that's just plain broken. :)

This isn't going to be the last device handling change; these changes
allow further tweaks to udev, hotplug, and related packages. Hopefully
nothing will break too badly along the way.

Bill



From ivazquez at ivazquez.net  Thu Jul 14 04:23:39 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Thu, 14 Jul 2005 00:23:39 -0400
Subject: PCMCIA & udev changes
In-Reply-To: <20050714041213.GA905@nostromo.devel.redhat.com>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
Message-ID: <1121315019.6290.2.camel@ignacio.lan>

On Thu, 2005-07-14 at 00:12 -0400, Bill Nottingham wrote:
> What does this mean for you, the developer?
> 
> - The use of /etc/hotplug.d and /etc/dev.d for the running of programs on
>   hotplug and udev events is officially deprecated.
>   
>   All programs that have been run in this way need to be converted to
>   RUN targets in udev rule files; these can be dropped in /etc/udev/rules.d.
>   Old dev.d and hotplug.d events will still be run in a compatibility mode
>   for now... I'm not yet sure how long we will continue to do so.

Where can we read up on the changes necessary for this?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/2b2794cb/attachment.sig>

From notting at redhat.com  Thu Jul 14 04:33:16 2005
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 14 Jul 2005 00:33:16 -0400
Subject: PCMCIA & udev changes
In-Reply-To: <1121315019.6290.2.camel@ignacio.lan>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
Message-ID: <20050714043316.GA1840@nostromo.devel.redhat.com>

Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> > - The use of /etc/hotplug.d and /etc/dev.d for the running of programs on
> >   hotplug and udev events is officially deprecated.
> >   
> >   All programs that have been run in this way need to be converted to
> >   RUN targets in udev rule files; these can be dropped in /etc/udev/rules.d.
> >   Old dev.d and hotplug.d events will still be run in a compatibility mode
> >   for now... I'm not yet sure how long we will continue to do so.
> 
> Where can we read up on the changes necessary for this?

There's some stuff in /usr/share/doc/udev-062/RELEASE-NOTES, but it's not
very elaborate.

Here's one simple example, from the alsa-utils package that lands tomorrow:

SUBSYSTEM=="sound", KERNEL=="pcm*"   RUN+="/sbin/salsa"

This, for any sound device with a name pcm*, runs /sbin/salsa. The '+=' means
that it's added in addition to any other RUN directives that might be queued for
this event.

When /sbin/salsa is run, it has all the usual environment variables expected
in a udev/hotplug script - DEVPATH, ACTION, etc.

Bill



From divij at innomedia.soft.net  Thu Jul 14 07:03:33 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Thu, 14 Jul 2005 12:33:33 +0530
Subject: setitimer
Message-ID: <1121324613.5129.2.camel@localhost.localdomain>

Hi,
    I want to know that setitimer can be used on a per thread basis or
not.

Thanks in Advance
Divij



From rms at 1407.org  Thu Jul 14 07:28:38 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Thu, 14 Jul 2005 08:28:38 +0100
Subject: No more right click terminal
In-Reply-To: <604aa79105071314411dc3a1ac@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
Message-ID: <1121326118.2792.10.camel@roque>

On Wed, 2005-07-13 at 17:41 -0400, Jeff Spaleta wrote:
> In broader strokes... I think gnome IS following lessons taken from
> existing credible studies as they become available. I think Sun's 2001
> study marked a turning point towards a general change to designing for

This study keeps being repeated every once and a while to try to prove
there is a significant study but I disagree. It is a very crappy study.

It has a small number of test subjects
Most test subjects had years of experience with Windows, CDE, and
others.

So:
  a) small number ==> nowhere near representative
  b) test subjects ==> opinions tainted from habits

Small changes I make on default desktops I install have proven to be
considered easier and more coherent by the users:
	* $HOME is desktop
	* a mix of two panels
	* shading instead of maximize on double click
	* menu key brings up main menu and few other short cuts
	* ...

In comparison with Sun's test study:
	a) I have tried only a slightly smaller number of users
	b) most of them don't have computer habits

So yeah, whatever, but don't bring that study up as if it is something
great and good, 'cause like Slowaris, it ain't.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/49862d8c/attachment.sig>

From ivazquez at ivazquez.net  Thu Jul 14 08:08:55 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Thu, 14 Jul 2005 04:08:55 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <20050714043316.GA1840@nostromo.devel.redhat.com>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
Message-ID: <1121328535.6290.14.camel@ignacio.lan>

If someone could please take a look at the devel branch of libifp in
Extras and see if it's okay wrt the new udev it would be much
appreciated, thanks.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/9f2c4637/attachment.sig>

From buildsys at redhat.com  Thu Jul 14 11:54:36 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 14 Jul 2005 07:54:36 -0400
Subject: rawhide report: 20050714 changes
Message-ID: <200507141154.j6EBsZ6X002766@porkchop.devel.redhat.com>

New package nspr
	Netscape Portable Runtime

New package pcmciautils
	PCMCIA utilities and initialization programs


Removed package pcmcia-cs

Updated Packages:

anaconda-10.3.0.5-1
-------------------
* Wed Jul 13 2005 Chris Lumens <clumens at redhat.com> 10.3.0.5-1
- Fix pygtk bug on progress bars.
- Bump ia64 boot.img size (katzj, #162801).
- Fix for clearpart --none (katzj, #162445).
- yum dependancy fixes (pnasrat).
- name.arch fix for kickstart (pnasrat).
- Fix multiple NICs in kickstart config files (#158566).

aspell-12:0.60.3-1
------------------
* Wed Jul 13 2005 Ivana Varekova <varekova at redhat.com> 12:0.60.3-1
- update to 0.60.3 - (bug 141968) thanks to Dawid Gajownik 
- add BuildRequires: ncurses-devel, gettext 
- add config script patch (thanks tmraz at redhat.com)
bug-buddy-1:2.11.0-1
--------------------
* Wed Jul 13 2005 Matthias Clasen <mclasen at redhat.com> 2.11.0-1
- Newer upstream version

file-4.14-1
-----------
* Thu Jul 14 2005 Radek Vokal <rvokal at redhat.com> - 4.14-1
- sync with upstream, patch clean-up

* Mon Jul 04 2005 Radek Vokal <rvokal at redhat.com> - 4.13-5
- fixed reiserfs check (#162378)

* Mon Apr 11 2005 Radek Vokal <rvokal at redhat.com> - 4.13-4
- check Cyrus files before Apple Quicktime movies (#154342)

finger-0.17-29
--------------
* Wed Jul 13 2005 Radek Vokal <rvokal at redhat.com> 0.17-29
- make finger world readable (#162643)

fonts-chinese-2.15-3
--------------------

fonts-japanese-0.20050222-5
---------------------------
* Thu Jul 14 2005 Akira TAGOH <tagoh at redhat.com> - 0.20050222-5
- use FAPIcidfmap instead of CIDFnmap for gs8.

fonts-korean-1.0.11-5
---------------------
* Thu Jul 14 2005 Akira TAGOH <tagoh at redhat.com> - 1.0.11-5
- use FAPIcidfmap instead of CIDFnmap for gs8.
gamin-0.1.2-1
-------------
* Wed Jul 13 2005 Daniel Veillard <veillard at redhat.com> 0.1.2-1
- inotify back end patches, ready for the new inotify support in kernel
- lot of server code cleanup patches
- fixed an authentication problem

* Fri Jun 10 2005 Daniel Veillard <veillard at redhat.com> 0.1.1-1
- gamin_data_conn_event fix
- crash from bug gnome #303932
- Inotify and mounted media #171201
- mounted media did not show up on Desktop #159748
- write may not be atomic
- Monitoring a directory when it is a file
- Portability to Hurd/Mach and various code cleanups
- Added support for ~ as user home alias in .gaminrc

ghostscript-8.15-0.rc3.5
------------------------
* Wed Jul 13 2005 Tim Waugh <twaugh at redhat.com> 8.15-0.rc3.5
- Split font configuration (bug #161187).
- Reverted this change:
  - Build requires xorg-x11-devel, not XFree86-devel.

gnome-doc-utils-0.3.1-1
-----------------------
* Wed Jul 13 2005 Matthias Clasen <mclasen at redhat.com> - 0.3.1-1
- Newer upstream version

hwdata-0.162-1
--------------
* Wed Jul 13 2005 Bill Nottingham <notting at redhat.com> - 0.162-1
- remove /etc/pcmcia/config, conflict with pcmcia-cs

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_37rh
------------------------------------------
* Wed Jul 13 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_37rh
- Add virtual dependencies to indicate what version of java-gcj-compat
  we are based on.
- Import java-gcj-compat 1.0.32.

lvm2-2.01.13-1.0
----------------
* Wed Jul 13 2005 Alasdair Kergon <agk at redhat.com> - 2.01.13-1.0
- Fix several bugs discovered in the last release.

mozilla-37:1.7.8-3
------------------
* Tue Jul 12 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.8-3
- Use system NSPR

openoffice.org-1:1.9.117-1.2.0.fc5
----------------------------------
* Wed Jul 13 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-1
- bump to next version and drop the integrated (finally) fpicker patch
- back to using stlport for now because I'm dubious
- rh#162984# fallbacks from en_AU to en_GB for wizards
- rh#160783# set a targetname for font when it's found
- add openoffice.org-1.9.117.rh163147.thorndale.fontconfig.patch
- add openoffice.org-1.9.117.ooo51912.nullpointer.wizards.patch for
  rh#161173#

rpm-4.4.1-22
------------
* Wed Jul 13 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.1-22
- zlib fix for CAN-2005-2096

selinux-policy-strict-1.25.2-2
------------------------------
* Wed Jul 13 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-2
- Allow klogin to read keytab file.
- Allow cvs to send mail

selinux-policy-targeted-1.25.2-2
--------------------------------
* Wed Jul 13 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-2
- Allow klogin to read keytab file.
- Allow cvs to send mail

udev-062-2
----------
* Fri Jul 08 2005 Bill Nottingham <notting at redhat.com> - 062-2
- update to 062
- use included ata_id, build usb_id
- load modules for pci, usb, pcmcia
- ship RELEASE-NOTES in %doc

wget-1.10-5
-----------
* Wed Jul 13 2005 Karsten Hopp <karsten at redhat.de> 1.10-5
- update german translation

yelp-2.11.1-1
-------------
* Wed Jul 13 2005 Matthias Clasen <mclasen at redhat.com> 2.11.1-1
- Newer upstream version

Broken deps for i386
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	mozilla-nss - 37:1.7.8-3.i386 requires mozilla-nspr = 37:1.7.8-3
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_37rh.ppc64 requires gjdoc
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	firstboot - 1.3.43-1.noarch requires system-config-display
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	selinux-policy-targeted-sources - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-strict-sources - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	mozilla-nss - 37:1.7.8-3.s390x requires mozilla-nspr = 37:1.7.8-3
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	dhcp - 10:3.0.2-14.FC5.s390x requires kernel >= 0:2.2.18
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	mozilla-nss - 37:1.7.8-3.s390 requires mozilla-nspr = 37:1.7.8-3
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	selinux-policy-targeted - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_37rh.s390x requires gjdoc
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-strict - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219



Broken deps for ia64
----------------------------------------------------------
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	mozilla-nss - 37:1.7.8-3.ia64 requires mozilla-nspr = 37:1.7.8-3
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_37rh.ia64 requires gjdoc



Broken deps for s390
----------------------------------------------------------
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_37rh.s390 requires gjdoc
	mozilla-nss - 37:1.7.8-3.s390 requires mozilla-nspr = 37:1.7.8-3
	selinux-policy-strict - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	dhcp - 10:3.0.2-14.FC5.s390 requires kernel >= 0:2.2.18
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	selinux-policy-strict-sources - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted-sources - 1.25.2-2.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging



Broken deps for x86_64
----------------------------------------------------------
	mozilla-nss - 37:1.7.8-3.i386 requires mozilla-nspr = 37:1.7.8-3
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	mozilla-nss - 37:1.7.8-3.x86_64 requires mozilla-nspr = 37:1.7.8-3
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)



Broken deps for ppc
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	mozilla-nss - 37:1.7.8-3.ppc requires mozilla-nspr = 37:1.7.8-3





From jspaleta at gmail.com  Thu Jul 14 12:11:26 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 14 Jul 2005 08:11:26 -0400
Subject: No more right click terminal
In-Reply-To: <1121326118.2792.10.camel@roque>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
Message-ID: <604aa791050714051125787aeb@mail.gmail.com>

On 7/14/05, Rui Miguel Seabra <rms at 1407.org> wrote:
> This study keeps being repeated every once and a while to try to prove
> there is a significant study but I disagree. It is a very crappy study.

feel free to get in touch with the gnome usability group... and
volunteer your services to produce and implement a less crappy study
with repeatable methodology so other people can call it crappy when
you release your results.  Debating the worth of any particular study,
here.. is pointless..

-jef



From dimi at lattica.com  Thu Jul 14 12:22:42 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 14 Jul 2005 08:22:42 -0400
Subject: NetworkManager
Message-ID: <1121343762.11210.84.camel@dimi>


I'm running FC4, and last night I was reading about NetworkManager,
and I realized I never tried it. So I do:
  $ su
  # /etc/init.d/NetworkManager start

It started alright, but everything (network) stopped working!
BTW, this is happening on a desktop with only a wired eth0.

I say 'F@#% it!' and I stop it quickly, but the network is still
down. I bounce eth0 once:
  # ifdown eth0
  # ifup eth0
Still no go. After a while I figure out that pings are working, but DNS
is foo-bared. Sure enough, NetworkManager completely erased my
/etc/resolv.conf! Needless to say, my resolv.conf was 100% hand-edited
with search and nameserver entries that NetworkManager can not possibly
guess. Why did it feel the need to mess with it?

Now, apart from the very frustrating experience, is this intended
behavior? If so, does it really have to be this way?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dimi at lattica.com  Thu Jul 14 12:36:50 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 14 Jul 2005 08:36:50 -0400
Subject: No more right click terminal
In-Reply-To: <604aa791050714051125787aeb@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
Message-ID: <1121344610.11210.99.camel@dimi>

On Thu, 2005-07-14 at 08:11 -0400, Jeff Spaleta wrote:
> Debating the worth of any particular study,
> here.. is pointless..

Very smart. It seems that _anything_ is pointless to discuss here.

Of course, you can argue till the cows come home that this is fedora,
and 'take this to other lists', but that is just a way to shut people
up. You can argue like that about *anything*, what is then the point of
this list?

Folks, most of the issues that people bring up are *valid* customer
complaints. Brushing them off (as it happens sooo often here) with
arguments like: 'you are not our customer', 'discuss it elsewhere, it is
pointless here', etc is just counterproductive.

As I understand it, the entire point of having a _community_ distro like
Fedora is to channel all this customer feedback into a better product.
Please stop with the 'pointless' comments already, they are not helpful.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sundaram at redhat.com  Thu Jul 14 12:47:40 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 18:17:40 +0530
Subject: No more right click terminal
In-Reply-To: <1121344610.11210.99.camel@dimi>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
Message-ID: <42D65EEC.1040205@redhat.com>

Dimi Paun wrote:

>On Thu, 2005-07-14 at 08:11 -0400, Jeff Spaleta wrote:
>  
>
>>Debating the worth of any particular study,
>>here.. is pointless..
>>    
>>
>
>Very smart. It seems that _anything_ is pointless to discuss here.
>  
>
GNOME development decisions shouldnt be discussed here. 

>Of course, you can argue till the cows come home that this is fedora,
>and 'take this to other lists', but that is just a way to shut people
>up. You can argue like that about *anything*, what is then the point of
>this list?
>  
>
Fedora development as a distribution and only that

>As I understand it, the entire point of having a _community_ distro like
>Fedora is to channel all this customer feedback into a better product.
>Please stop with the 'pointless' comments already, they are not helpful.
>
>  
>
Exactly

regards
Rahul



From veillard at redhat.com  Thu Jul 14 12:54:54 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 14 Jul 2005 08:54:54 -0400
Subject: No more right click terminal
In-Reply-To: <1121344610.11210.99.camel@dimi>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
Message-ID: <20050714125454.GC3984@redhat.com>

On Thu, Jul 14, 2005 at 08:36:50AM -0400, Dimi Paun wrote:
> On Thu, 2005-07-14 at 08:11 -0400, Jeff Spaleta wrote:
> > Debating the worth of any particular study,
> > here.. is pointless..
> 
> Very smart. It seems that _anything_ is pointless to discuss here.
> 
> Of course, you can argue till the cows come home that this is fedora,
> and 'take this to other lists', but that is just a way to shut people
> up. You can argue like that about *anything*, what is then the point of
> this list?
> 
> Folks, most of the issues that people bring up are *valid* customer
> complaints. Brushing them off (as it happens sooo often here) with
> arguments like: 'you are not our customer', 'discuss it elsewhere, it is
> pointless here', etc is just counterproductive.
> 
> As I understand it, the entire point of having a _community_ distro like
> Fedora is to channel all this customer feedback into a better product.
> Please stop with the 'pointless' comments already, they are not helpful.

  It is pointless to argue here about stuff that can't be changed within
the reals of the Fedora project. To get back to specific, if you have a
itch to scratch with a specific behaviour on the GNOME desktop, it is
very unlikely to get changed here by applying a patch against the upstream
code or data. The correct behaviour as an Open Source project participant is
to debate it upstream where there is an infrastructure (usability team, tools
and mailing-list) in place to get this processed. If there was no upstream
venue, then yes here would be an alternate forum by lack of better choice
but Jeff is 100% on-spot in this case, this is a GNOME usability request,
and discussion should be process there, not here.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From caolanm at redhat.com  Thu Jul 14 12:55:57 2005
From: caolanm at redhat.com (Caolan McNamara)
Date: Thu, 14 Jul 2005 13:55:57 +0100
Subject: tips on reporting OOo bugs
Message-ID: <1121345757.3247.9.camel@localhost.localdomain>

Some tips for reporting bugs that might be helpful. OOo is quite big,
and it links to and uses extensively a lot of stuff and so hoovers up a
lot of problems that are not always OOo bugs, so...

A) A crash on startup might be a crash in some opengl lib, not OOo
itself, get the source at
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=108799
and gcc testgl.c -o testgl -L/usr/X11R6/lib -lX11 -lGL to compile
and run it, if it also crashes it's not an OOo bug.

B) if it happens on an x86_64 box, remember that OOo is a 32bit app,
firefox is 32bit on the same platforms, see if it has the same problem
as well.

C) generally check that similiar applications don't behave the same way,
e.g. if firefox/gedit/glxgears do the same thing as OOo then it's
unlikely to be an OOo bug

D) if the crash dialog appears, paste in the stacktrace it gives you
into your bugreport.

E) mention if you are using KDE or GNOME, it often matters. If you have
non fedora-supplied kde theme engines installed, try one of the
supported ones.

F) if there is an error/warning message, say what the error message is

G) if it happens with a particular document, attach the document. If you
can, delete the parts of the document down to the smallest test case
that reproduces the problem. "Scroll to page 912 and the graphic is
misplaced" is way less appealing than having a one page example.

H) if you think there is something wrong with what is being displayed,
attach a screenshot. I might not understand your description. e.g.
"formula font is wrong", is it the font used in the text area for
editing the formula, or is it the font used to display the formula. Did
you mean the math editor, or did you actually mean formulas in calc.

I) Try not to tag things onto bugs with "and this unrelated thing
doesn't work", or "yeah that fixed it, but something different is still
not the way I want it", mutating bugs are really difficult to deal with.
There's no problem opening multiple bugs, it's easier to merge bugs
together if they turn out to be the same thing than to unmunge them into
seperate problems.

J) if you know you have something unusual about your setup, mention it.
e.g. .doc documents created with msword running under *wine* don't open
in OOo as opposed to just saying ".doc files don't open in OOo". Or say
"saving to a samba share doesn't work", vs "saving doesn't work".

K) if you can, install the debuginfo and 
> gdb /usr/lib/openoffice.org/program/soffice.bin
(gdb) run -writer
(gdb) bt
and paste in the backtrace

(-writer or -calc or -impress or -math or -draw)

L) it's nice when someone finds that a bug got cleared in an update and
mentions it in an old unclosed bug, but not so useful when it's an
unprompted note to say that the problem is still there.

M) "this is unacceptable" is not good motivational practice.

C.



From ph18 at cornell.edu  Thu Jul 14 12:56:49 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Thu, 14 Jul 2005 08:56:49 -0400
Subject: No more right click terminal
In-Reply-To: <42D5A34D.5060307@tlarson.com>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<42D5A34D.5060307@tlarson.com>
Message-ID: <42D66111.6070202@cornell.edu>

Tyler Larson wrote:

>
> I personally think that removing the terminal from the context menu is 
> the correct thing to do (it should have stayed on the panel with the 
> other launchers--and it sure as hell better go back). Still, my 
> initial reaction was mild outrage--it felt like yet another personal 
> attack against me. Another "you don't belong here" message from GNOME. 
> I certainly understand why others were angry.

    Yeah,  a launcher on the panel would be nice too.

    There are three things I use Gnome for

* launching terminals
* shutting the computer down
* setting the audio volume

    Open Office?  Evolution?  Give me a break.  I'd personally be happy 
with a radically simplified interface:  a button to launch a terminal,  
a button to shut the computer down,  and a slider to adjust audio volume.



From mitr at volny.cz  Thu Jul 14 13:07:38 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 14 Jul 2005 15:07:38 +0200
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <1121344610.11210.99.camel@dimi>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
Message-ID: <20050714130732.GE16452@chrys.ms.mff.cuni.cz>

On Thu, Jul 14, 2005 at 08:36:50AM -0400, Dimi Paun wrote:
> Very smart. It seems that _anything_ is pointless to discuss here.
Anything except development of Fedora.

> You can argue like that about *anything*, what is then the point of
> this list?
Development of Fedora.  The fact that it is not discussed here
much doesn't make other topics any more welcome.

> Folks, most of the issues that people bring up are *valid* customer
> complaints.
- Fedora has customers?
- This list is not for recieving customer complaints.

> Brushing them off (as it happens sooo often here) with
> arguments like: 'you are not our customer', 'discuss it elsewhere, it is
> pointless here', etc is just counterproductive.
Hijacking what is supposed to be a development list is not
counterproductive?

> As I understand it, the entire point of having a _community_ distro like
> Fedora is to channel all this customer feedback into a better product.
Patches are the preferred form of feedback.


Yes, I realize I might have been too harsh, I'm sorry if that seems to be
a personal attack; it is not meant to be personal.


I'd like everyone here to take a few minutes and read recent
fedora-extras-list or fedora-maintainers-readonly archives.
That's what development discussions look like, and not
what one can see on this list.  Sending off-topic mail here
only means that development discussions will move to
more closed places (fedora-maintainers), or stay at more closed
places (internal Red Hat lists).  That in turn makes initial
contributions of interested developers harder, hurting the
future of Fedora.
	Mirek



From mike at miketc.com  Thu Jul 14 13:09:59 2005
From: mike at miketc.com (Mike Chambers)
Date: Thu, 14 Jul 2005 08:09:59 -0500
Subject: FC4 + rawhide
Message-ID: <1121346599.4897.1.camel@scrappy.miketc.com>

Is it just me, or did the fonts change in the menus and windows when
updating to rawhide from FC4?  Is this from gtk or something else and is
it still that way or been changed back?

I ask because I updated couple days ago, but I reinstalled 4 and haven't
used rawhide again yet.

-- 
Mike Chambers
Madisonville, KY

"Everything is always harder, before it's easier!"



From dennis at ausil.us  Thu Jul 14 13:19:19 2005
From: dennis at ausil.us (Dennis Gilmore)
Date: Thu, 14 Jul 2005 08:19:19 -0500 (CDT)
Subject: NetworkManager
In-Reply-To: <1121343762.11210.84.camel@dimi>
References: <1121343762.11210.84.camel@dimi>
Message-ID: <53621.68.254.239.135.1121347159.squirrel@ausil.us>


> Now, apart from the very frustrating experience, is this intended
> behavior? If so, does it really have to be this way?
>
Yes its intended behaviour.  Networkmanager at the moment works with dhcp
only   its intended  more for laptops where you will be using many
different networks.  it makes it easy to change.  and different networks
have different requirements.  one thing that would be a nice addon.  is if
the dhcp server gives out a proxy server it setsup  iptables rules to
forward all traffic to port 80 and 21 to the proxy server.  so you never
need to configure browsers, etc

Dennis



From fedora at camperquake.de  Thu Jul 14 13:21:51 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 14 Jul 2005 15:21:51 +0200
Subject: FC4 + rawhide
In-Reply-To: <1121346599.4897.1.camel@scrappy.miketc.com>
References: <1121346599.4897.1.camel@scrappy.miketc.com>
Message-ID: <20050714152151.40ce8313@nausicaa.camperquake.de>

Hi.

Mike Chambers <mike at miketc.com> wrote:

> Is it just me, or did the fonts change in the menus and windows when
> updating to rawhide from FC4?  Is this from gtk or something else and is
> it still that way or been changed back?

Rawhide GTK has changed it's rendering backend to cairo, this might
have changed font rendering, also.

-- 
"The only problem with drinking to drown your sorrows is that they very
quickly learn to swim."  -- Janet McKnight



From rms at 1407.org  Thu Jul 14 13:28:59 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Thu, 14 Jul 2005 14:28:59 +0100
Subject: No more right click terminal
In-Reply-To: <42D65EEC.1040205@redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>  <42D65EEC.1040205@redhat.com>
Message-ID: <1121347739.2755.48.camel@roque>

On Thu, 2005-07-14 at 18:17 +0530, Rahul Sundaram wrote:
> Dimi Paun wrote:
> >Very smart. It seems that _anything_ is pointless to discuss here.
> >
> GNOME development decisions shouldnt be discussed here. 

Most of the little changes I did are matter of default settings, not of
general development. So they definitely do fit here.

> Fedora development as a distribution and only that

And bad defaults are what?

I see a dangerous circular reasoning here:

  1. gah... I have this problem
  2. complain upstream
  1 (now in upstream). gah... I have this problem
  3. complain to your distribution (sometimes even 2. joins the fray,
     some even add childish comments like "that's crack *")

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/7ec80fb3/attachment.sig>

From jspaleta at gmail.com  Thu Jul 14 13:40:57 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 14 Jul 2005 09:40:57 -0400
Subject: No more right click terminal
In-Reply-To: <1121344610.11210.99.camel@dimi>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
Message-ID: <604aa79105071406403094ff4c@mail.gmail.com>

On 7/14/05, Dimi Paun <dimi at lattica.com> wrote:
> Of course, you can argue till the cows come home that this is fedora,
> and 'take this to other lists', but that is just a way to shut people
> up. You can argue like that about *anything*, what is then the point of
> this list?

I think you grossly misinterpret my goal.  My goal is to get the
people with gripes hooked into the correct location to talk to the
correct group of people so those complaints have a chance to be turned
into constructive action. Idle complaints about gnome usability
changes in the fedora lists serve no constructive purpose.  People who
want to see better usability testing, and can volunteer their personal
resources into that effort, need to get in touch with the gnome
usability group and affect change upstream.    You aren't going to
impact gnome's usability practices by jabbering about it here.  All
you are going to accomplish is to fan the flames of frustration.
Discussion that has no hope of leading to action is unconstructive.

> 
> Folks, most of the issues that people bring up are *valid* customer
> complaints. 

If you continue to labor under the constraining definitions of a
traditional model where a "customer" "buys" a "product", you will
continue to be frustrated by the "contributor" process by which
everyone working on this "project" needs to be familiar with.  Gnome
has a usibility group, everyone interested in sound and more frequent
usability testing for gnome applications should interface with that
group specifically. Extended debate, in this list, about the technical
merits of one methodology versus another, serves no constructive
purpose.  Even if concensous on what needs to be done is reached on
this list (highly unlikely) the conclusions drawn count for very
little.. becuase the people with whom the discussion needs to happen
are the gnome usability team, a group of people who meet and discuss
as a group in a different location.

My personal feelings on the matter are that people who refuse to move
discussion to the most effective upstream forum, are delibrately
attempting to cause problems or are only interested in browbeating
other people with their opinions in an effort to score debating
experience points.  Once an issue or complaint is brought it... the
quicker it can be moved to the appropriate upstream  forum or group
the less frustrating it is for everyone.

-jef"If i wanted to shut people up, id choke off this thread by
writing 20 page responses to this list so people who just start
ignoring the thread completely"spaleta



From sundaram at redhat.com  Thu Jul 14 13:45:35 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 19:15:35 +0530
Subject: No more right click terminal
In-Reply-To: <1121347739.2755.48.camel@roque>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>
	<42D65EEC.1040205@redhat.com> <1121347739.2755.48.camel@roque>
Message-ID: <42D66C7F.1020206@redhat.com>

Rui Miguel Seabra wrote:

>On Thu, 2005-07-14 at 18:17 +0530, Rahul Sundaram wrote:
>  
>
>>Dimi Paun wrote:
>>    
>>
>>>Very smart. It seems that _anything_ is pointless to discuss here.
>>>
>>>      
>>>
>>GNOME development decisions shouldnt be discussed here. 
>>    
>>
>
>Most of the little changes I did are matter of default settings, not of
>general development. So they definitely do fit here.
>  
>
Fedora has a explicit design goal to stick close to upstream defaults. 
Maintaining non-upstream patches affects development and is a general 
development issue. We have to avoid that as much as possible. If you 
think GNOME has bad default settings that isnt specific to Fedora. So 
get it fixed upstream and everybody else will inherit that

regards
Rahul



From dcbw at redhat.com  Thu Jul 14 14:16:17 2005
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 14 Jul 2005 10:16:17 -0400
Subject: NetworkManager
In-Reply-To: <53621.68.254.239.135.1121347159.squirrel@ausil.us>
References: <1121343762.11210.84.camel@dimi>
	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
Message-ID: <1121350577.14067.6.camel@dcbw.boston.redhat.com>

On Thu, 2005-07-14 at 08:19 -0500, Dennis Gilmore wrote:
> > Now, apart from the very frustrating experience, is this intended
> > behavior? If so, does it really have to be this way?
> >
> Yes its intended behaviour.  Networkmanager at the moment works with dhcp
> only   its intended  more for laptops where you will be using many
> different networks.  it makes it easy to change.  and different networks
> have different requirements.  one thing that would be a nice addon.  is if
> the dhcp server gives out a proxy server it setsup  iptables rules to
> forward all traffic to port 80 and 21 to the proxy server.  so you never
> need to configure browsers, etc

It does work with any static IP address you have configured with
system-config-network.  It will apply the IP & DNS configuration you've
selected using system-config-network Profiles on startup.  NM blows away
your /etc/resolv.conf because it uses a local caching nameserver to deal
with horrible glibc resolver dropouts when network switches occur.
That's not likely to change, what may change would be the ability to add
custom entries to the caching nameserver's config.

Dan



From sundaram at redhat.com  Thu Jul 14 14:27:25 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 19:57:25 +0530
Subject: tips on reporting OOo bugs
In-Reply-To: <1121345757.3247.9.camel@localhost.localdomain>
References: <1121345757.3247.9.camel@localhost.localdomain>
Message-ID: <42D6764D.9060400@redhat.com>

Caolan McNamara wrote:

>Some tips for reporting bugs that might be helpful. OOo is quite big,
>and it links to and uses extensively a lot of stuff and so hoovers up a
>lot of problems that are not always OOo bugs, so...
>
I have imported this into http://fedoraproject.org/wiki/BugsReports. 
Would appreciate if other developer would add package specific 
guidelines in there so we have a canonical reference for end users to 
verify when reporting bugs. It would also help the launch of Fedora bug 
squad in the near future

regards
Rahul



From rms at 1407.org  Thu Jul 14 14:29:18 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Thu, 14 Jul 2005 15:29:18 +0100
Subject: No more right click terminal
In-Reply-To: <42D66C7F.1020206@redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <42D65EEC.1040205@redhat.com>
	<1121347739.2755.48.camel@roque>  <42D66C7F.1020206@redhat.com>
Message-ID: <1121351358.2755.55.camel@roque>

On Thu, 2005-07-14 at 19:15 +0530, Rahul Sundaram wrote:
> think GNOME has bad default settings that isnt specific to Fedora. So 
> get it fixed upstream and everybody else will inherit that

Circular reasoning, step in N. 2 ;)

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/29cc4c61/attachment.sig>

From sundaram at redhat.com  Thu Jul 14 14:31:49 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 20:01:49 +0530
Subject: No more right click terminal
In-Reply-To: <1121351358.2755.55.camel@roque>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>
	<42D65EEC.1040205@redhat.com>	<1121347739.2755.48.camel@roque>
	<42D66C7F.1020206@redhat.com> <1121351358.2755.55.camel@roque>
Message-ID: <42D67755.5090209@redhat.com>

Rui Miguel Seabra wrote:

>On Thu, 2005-07-14 at 19:15 +0530, Rahul Sundaram wrote:
>  
>
>>think GNOME has bad default settings that isnt specific to Fedora. So 
>>get it fixed upstream and everybody else will inherit that
>>    
>>
>
>Circular reasoning, step in N. 2 ;)
>
>Rui
>  
>
I am curious. How is this circular reasoning?

regards
Rahul



From dimi at lattica.com  Thu Jul 14 14:56:52 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 14 Jul 2005 10:56:52 -0400
Subject: No more right click terminal
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>
	<42D65EEC.1040205@redhat.com>
Message-ID: <032001c58884$45522880$b6491b31@td612671>

> Fedora development as a distribution and only that

OK, let's see:
  -- software issues: upstream. Check.
  -- configuration issues: upstream. Check.
  -- packaging issues: upstream. Check.
  -- policy issues: upstream. Check.
  -- file/directory issues: upstream. Check.

What's left? Oh, what packages to include. Right.
But that is decided in a closed circle anyway,
without any community involvement.

Take away all discussions according to the above
criteria, and you're left with nothing. Zilch.

Great way to build a community.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From skvidal at phy.duke.edu  Thu Jul 14 15:01:30 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 14 Jul 2005 11:01:30 -0400
Subject: No more right click terminal
In-Reply-To: <032001c58884$45522880$b6491b31@td612671>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>
	<42D65EEC.1040205@redhat.com> <032001c58884$45522880$b6491b31@td612671>
Message-ID: <1121353290.13861.38.camel@cutter>


> What's left? Oh, what packages to include. Right.
> But that is decided in a closed circle anyway,
> without any community involvement.

it is?

extras is decided in the open
much of core is decided in the open

also you forgot to look at all the infrastructure bits that fedora does:
anaconda, pup, system-config-*, etc.

-sv




From dimi at lattica.com  Thu Jul 14 15:06:14 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 14 Jul 2005 11:06:14 -0400
Subject: No more right click terminal
References: <1121248417.16074.19.camel@goose><55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org><1121272795.13335.18.camel@localhost.localdomain><1121282867.21244.27.camel@rousalka.dyndns.org><42D5743A.6010300@shahms.com><1121287685.28486.18.camel@rousalka.dyndns.org><604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque><604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>
	<20050714125454.GC3984@redhat.com>
Message-ID: <033401c58885$94407f90$b6491b31@td612671>

From: "Daniel Veillard" <veillard at redhat.com>
>   It is pointless to argue here about stuff that can't be changed within
> the reals of the Fedora project. To get back to specific, if you have a
> itch to scratch with a specific behaviour on the GNOME desktop, it is
> very unlikely to get changed here by applying a patch against the upstream
> code or data.

This is missing the point. In principle I can agree with this stance,
but what is upsetting is the attitude. In this particular case things
would have died off at that comment, if Jeff wouldn't have added the
"go away, it's pointless" comment. And I'm not picking on him, it's
what people are doing around here for some time now. Very often. Most
threads ends up with a condecending message of sorts.

I'm not sure if people realize how unwelcomming this sort of attitude is.
It's very much reminiscent of the in-group environment enjoyed in the core
BSD circles. It is bad. This is not how you build a community, even if
you are correct at a rational level.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dimi at lattica.com  Thu Jul 14 15:13:01 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 14 Jul 2005 11:13:01 -0400
Subject: No more right click terminal
References: <1121143049.3521.16.camel@localhost.localdomain><1121245649.12224.28.camel@localhost.localdomain><1121248417.16074.19.camel@goose><55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org><1121272795.13335.18.camel@localhost.localdomain><1121282867.21244.27.camel@rousalka.dyndns.org><42D5743A.6010300@shahms.com><1121287685.28486.18.camel@rousalka.dyndns.org><604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque><604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi><42D65EEC.1040205@redhat.com>
	<032001c58884$45522880$b6491b31@td612671>
	<1121353290.13861.38.camel@cutter>
Message-ID: <033c01c58886$86d30a20$b6491b31@td612671>

From: "seth vidal" <skvidal at phy.duke.edu>
> much of core is decided in the open

Not really. We are informed what's happening, I can't recall
a single instance where feedback from the list reverted a
decision to include/exclude a package from core.
But this is a different matter, it was just an example.

> also you forgot to look at all the infrastructure bits that fedora does:
> anaconda, pup, system-config-*, etc.

No, I did not. But if you are consistent, it can be argued that
these are different projects, and issues should be discussed
upstream.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sundaram at redhat.com  Thu Jul 14 15:15:12 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 20:45:12 +0530
Subject: No more right click terminal
In-Reply-To: <033c01c58886$86d30a20$b6491b31@td612671>
References: <1121143049.3521.16.camel@localhost.localdomain><1121245649.12224.28.camel@localhost.localdomain><1121248417.16074.19.camel@goose><55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org><1121272795.13335.18.camel@localhost.localdomain><1121282867.21244.27.camel@rousalka.dyndns.org><42D5743A.6010300@shahms.com><1121287685.28486.18.camel@rousalka.dyndns.org><604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque><604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi><42D65EEC.1040205@redhat.com>	<032001c58884$45522880$b6491b31@td612671>	<1121353290.13861.38.camel@cutter>
	<033c01c58886$86d30a20$b6491b31@td612671>
Message-ID: <42D68180.6060204@redhat.com>

Hi

>No, I did not. But if you are consistent, it can be argued that
>these are different projects, and issues should be discussed
>upstream.
>  
>
Fedora *is*  upstream for several of these projects

regards
Rahul



From jspaleta at gmail.com  Thu Jul 14 15:35:32 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 14 Jul 2005 11:35:32 -0400
Subject: No more right click terminal
In-Reply-To: <033401c58885$94407f90$b6491b31@td612671>
References: <1121248417.16074.19.camel@goose>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
Message-ID: <604aa79105071408351908315@mail.gmail.com>

On 7/14/05, Dimi Paun <dimi at lattica.com> wrote:
> This is missing the point. In principle I can agree with this stance,
> but what is upsetting is the attitude. In this particular case things
> would have died off at that comment, if Jeff wouldn't have added the
> "go away, it's pointless" comment. 

It's also pointless to talk about my attitude on this list. If you
have a problem with my attitude take it upstream to me.

-jef



From toshio at tiki-lounge.com  Thu Jul 14 16:31:49 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Thu, 14 Jul 2005 12:31:49 -0400
Subject: No more right click terminal
In-Reply-To: <033401c58885$94407f90$b6491b31@td612671>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>
	<20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
Message-ID: <1121358709.4718.34.camel@localhost>

On Thu, 2005-07-14 at 11:06 -0400, Dimi Paun wrote:

> I'm not sure if people realize how unwelcomming this sort of attitude is.
> It's very much reminiscent of the in-group environment enjoyed in the core
> BSD circles. It is bad. This is not how you build a community, even if
> you are correct at a rational level.

I agree with the totality of this portion.  Namely:
1) Many of the issues raised on this list do not belong here.
2) Many times the off-topic threads end with rude comments.
3) This is not a good way to encourage people to contribute to Fedora.

Ideas (possibly cracktastic) to change this:

1) Boilerplate similar to POSTISOFFTOPIC but specifically for addressing
issues to upstream.  A group of  volunteers to send the actual message
whenever a post is off topic.  Everyone else agrees to ignore off-topic
posts.

2) Start a project to package different default values for Extras.  We
have redhat-rpm-config changing rpm and fedora-release changing the
config of yum.  Maybe there should be a poweruser-gconf-tweaks.  (More
seriously, it should probably be more like config-nautilus-nonspatial,
config-rpmbuild-userdirs, config-metacity-focusfollows, etc)  this can
work for things that just require default config changes but will not
work for compilation/upstream code changes.

3) Express interest in following upstream developments.  Encourage the
opening of bugzilla.redhat.com bugs with upstream bug #'s for these
issues.  There's no commitment to make changes, just a commitment to
actively monitor what upstream has to say about the issue and if
upstream commits to making a change, we'll do the same.

4) <Your wildly creative back of the envelope idea here>

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/463b4252/attachment.sig>

From sundaram at redhat.com  Thu Jul 14 16:41:57 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 22:11:57 +0530
Subject: Taking up work (was: Re: No more right click terminal)
In-Reply-To: <1121358709.4718.34.camel@localhost>
References: <1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>	<20050714125454.GC3984@redhat.com>	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
Message-ID: <42D695D5.5030204@redhat.com>

Hi

>
>1) Boilerplate similar to POSTISOFFTOPIC but specifically for addressing
>issues to upstream.  A group of  volunteers to send the actual message
>whenever a post is off topic.  Everyone else agrees to ignore off-topic
>posts.
>  
>
Ok. This one is easy. Just register yourself in fedoraproject.org/wiki 
and let me know your username offlist. I will add you to the edit group. 
You can go ahead and create templates then.


>2) Start a project to package different default values for Extras.  We
>have redhat-rpm-config changing rpm and fedora-release changing the
>config of yum.  Maybe there should be a poweruser-gconf-tweaks.  (More
>seriously, it should probably be more like config-nautilus-nonspatial,
>config-rpmbuild-userdirs, config-metacity-focusfollows, etc)  this can
>work for things that just require default config changes but will not
>work for compilation/upstream code changes.
>  
>
I would prefer people working on documenting these. A good desktop users 
guide and "power" user FAQ's  for Fedora which details out the common 
changes such as these would be useful. I dont think installing different 
packages for trivial changes such as these is really a good idea. What 
if you install this package and then change the configuration to a 
conflicting value?

>3) Express interest in following upstream developments.  Encourage the
>opening of bugzilla.redhat.com bugs with upstream bug #'s for these
>issues.  There's no commitment to make changes, just a commitment to
>actively monitor what upstream has to say about the issue and if
>upstream commits to making a change, we'll do the same.
>
Oh. I just got flamed a couple of days back for telling people to report 
bugs rather than rant on IRC channels and user lists. I am supposed to 
be fixing bugzilla to be more end user friendly first. Dont ask me how. 
I have no idea

regards
Rahul



From jkeating at j2solutions.net  Thu Jul 14 16:54:14 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 14 Jul 2005 09:54:14 -0700
Subject: No more right click terminal
In-Reply-To: <20050714125454.GC3984@redhat.com>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>  <20050714125454.GC3984@redhat.com>
Message-ID: <1121360055.31376.78.camel@prometheus.gamehouse.com>

On Thu, 2005-07-14 at 08:54 -0400, Daniel Veillard wrote:
>   It is pointless to argue here about stuff that can't be changed within
> the reals of the Fedora project. To get back to specific, if you have a
> itch to scratch with a specific behaviour on the GNOME desktop, it is
> very unlikely to get changed here by applying a patch against the upstream
> code or data. The correct behaviour as an Open Source project participant is
> to debate it upstream where there is an infrastructure (usability team, tools
> and mailing-list) in place to get this processed. If there was no upstream
> venue, then yes here would be an alternate forum by lack of better choice
> but Jeff is 100% on-spot in this case, this is a GNOME usability request,
> and discussion should be process there, not here.

What users could hope for is that those representatives of the Gnome
development group within @redhat could be the voice of @redhat's users,
so that the gnome group doesn't get more and more joe-random-opinion (of
which to ignore), they can get a more aggregated user base opinion from
vendor representatives.

-- 
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



From jspaleta at gmail.com  Thu Jul 14 17:03:48 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 14 Jul 2005 13:03:48 -0400
Subject: No more right click terminal
In-Reply-To: <1121358709.4718.34.camel@localhost>
References: <1121248417.16074.19.camel@goose> <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
Message-ID: <604aa79105071410036bc73ee@mail.gmail.com>

On 7/14/05, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> 1) Boilerplate similar to POSTISOFFTOPIC but specifically for addressing
> issues to upstream.  A group of  volunteers to send the actual message
> whenever a post is off topic.  Everyone else agrees to ignore off-topic
> posts.

Are you prepared to enforce that "agreement" by banning people who
continue to responde to threads that are off-topic?  I'm prepared to
"agree" to not post on a thread that has received a postisofftopic
designation, just as long as people who don't abide by that agreement
are shown the door.


> 2) Start a project to package different default values for Extras.  We
> have redhat-rpm-config changing rpm and fedora-release changing the
> config of yum.  Maybe there should be a poweruser-gconf-tweaks.  (More
> seriously, it should probably be more like config-nautilus-nonspatial,
> config-rpmbuild-userdirs, config-metacity-focusfollows, etc)  this can
> work for things that just require default config changes but will not
> work for compilation/upstream code changes.

I really don't think you a whole slew of individual config tools for
individual gconf key settings.
Can't you do this sort of thing for gnome desktops by providing
pre-packaged sabayon profiles moving forward? Since sabayon seems to
be exactly the tool aimed at administrors to created pre-cooked user
profiles and apply those profiles to a user account as needed.

-jef



From dennis at ausil.us  Thu Jul 14 17:26:37 2005
From: dennis at ausil.us (Dennis Gilmore)
Date: Thu, 14 Jul 2005 12:26:37 -0500
Subject: NetworkManager
In-Reply-To: <1121350577.14067.6.camel@dcbw.boston.redhat.com>
References: <1121343762.11210.84.camel@dimi>	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
Message-ID: <42D6A04D.3090002@ausil.us>

Dan Williams wrote:

>It does work with any static IP address you have configured with
>system-config-network.  It will apply the IP & DNS configuration you've
>selected using system-config-network Profiles on startup.  NM blows away
>your /etc/resolv.conf because it uses a local caching nameserver to deal
>with horrible glibc resolver dropouts when network switches occur.
>That's not likely to change, what may change would be the ability to add
>custom entries to the caching nameserver's config.
>
>Dan
>  
>
My Bad, 
i havent had anything in system-config-network for along time.  ill have 
to try it out.

Dennis



From aoliva at redhat.com  Thu Jul 14 17:32:52 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 14 Jul 2005 14:32:52 -0300
Subject: No more right click terminal
In-Reply-To: <1121274056.10565.15.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
Message-ID: <orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>

On Jul 13, 2005, Colin Walters <walters at redhat.com> wrote:

> Think of it this way: what if GNOME's historical audience had been
> musicians?  Then the right click menu might have had 
> "Open Musical Score Composer".  Having that makes as much sense to the
> general population as "Open Terminal" does.

FWIW, when I first introduced Cygwin to a musician friend of mine, he
absolutely *loved* the ability to issue commands without having to
point and click, and the ability to write scripts to automate common
or repetitive tasks.

Terminals should not be thought of as power-users only; they're useful
for everybody.  Perhaps our desktop approach should take a stance
similar to AIX SMIT (sp?), a system administration front-end that
would not only enable you to perform various tasks with a point&click
interface, but *also* let you know the commands it was running to
perform those tasks.  I'm told Autocad is very much like this as well,
and even architects without any prior programming expertise end up
being able to automate tasks using the lisp-based programming
interface, which is one of the features that makes it so powerful.

This gave you the option to remain clueless if you wanted to, but also
to learn the underlying infrastructure if you chose to, such that you
could perform the same commands more efficiently afterwards, even in
situations in which a GUI is not an option.

The GUI shouldn't be the whole picture, it's just part of the picture.
Every user interface should expose a model through an API in a
powerful scripting language that enables people to automate tasks
should they choose to (*).  Point&click is just *way* too annoying for
things you have to do often and/or repetitively.  Letting people learn
the underlying API through point&click brings the best of both worlds.

(*) Although I always believed this, Scott Collins confirmed that in
his talk at FISL 6.0, ``Building User Interfaces that Work''.

Sure enough, the underlying API needs not be shell-based.  But you
pretty much need a terminal to run python or whatever other scripting
language your API is designed for.

> With respect to the interface changing; that's true, but it seems to me
> that the GNOME/Fedora interface has been changing substantially in other
> ways (e.g. panel revamp from FC2->FC3)

Did it change?  I didn't notice any changes whatsoever in my panel.
Sure enough, I would, should I wipe out all of my gnome settings and
started from scratch, I guess.  (Un?)fortunately there's no easy way
to track the defaults while keeping the settings you've overridden,
AFAIK.  Open Terminal, OTOH, has changed regardless of my settings.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From sundaram at redhat.com  Thu Jul 14 17:39:06 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 14 Jul 2005 23:09:06 +0530
Subject: No more right click terminal
In-Reply-To: <orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <42D6A33A.5010902@redhat.com>

Hi

>Did it change?  I didn't notice any changes whatsoever in my panel.
>Sure enough, I would, should I wipe out all of my gnome settings and
>started from scratch, I guess.  (Un?)fortunately there's no easy way
>to track the defaults while keeping the settings you've overridden,
>AFAIK.  Open Terminal, OTOH, has changed regardless of my settings.
>
>  
>
Yes. Till FC2 there was a single panel configured to be on the bottom 
with a main menu. FC3 onwards have adopted the upstream defaults for the 
panel arrangement

regards
Rahul



From notting at redhat.com  Thu Jul 14 20:50:12 2005
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 14 Jul 2005 16:50:12 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <1121328535.6290.14.camel@ignacio.lan>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
Message-ID: <20050714205012.GA20299@nostromo.devel.redhat.com>

Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> If someone could please take a look at the devel branch of libifp in
> Extras and see if it's okay wrt the new udev it would be much
> appreciated, thanks.

It looks sane to me; I don't have the hardware to test it.

Bill



From omniuni at gmail.com  Thu Jul 14 20:55:07 2005
From: omniuni at gmail.com (OmniUni)
Date: Thu, 14 Jul 2005 13:55:07 -0700
Subject: Cutting Edge
Message-ID: <603d1b680507141355264aec3@mail.gmail.com>

Looking over the recent editions of this list, I have noticed that in many 
respects, fedora development is stuck in the past.

Fedora Core is supposed to be a cutting edge distro, and for the most part, 
it is. As a community, however, we must not be afraid to bring up new ideas 
to a distribution with so much a standardized history. For Fedora to remain 
cutting edge, it must be willing to change. I am a KDE user, and I am 
because I find it easier, faster, lighter, more stable, more friendly, more 
cusomizable, more elegant, and more powerful than GNOME. Will this change? 
perhaps. I used to like GNOME better, but that changed when Sawfish changed 
to Metacity. (around RHL 7.3-- 8.0 was metacity) Will requesting that Fedora 
become KDE based instead of GNOME based be likely to make a major impact 
here? no. Is it important that I request? yes. I do so, because it alerts 
the developers to views of Feora Core's users. OpenSource must be about Open 
Minds as well as free software. I am up to a lively discussion about KDE vs. 
GNOME, and a friendly reminder that GNOME must remain the focus of Fedora 
Core for now, but I certainly hope that I will not get any responses that 
look down upon me for expressing my views.

-OmniUni at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/7203b38f/attachment.htm>

From perbj at stanford.edu  Thu Jul 14 21:16:13 2005
From: perbj at stanford.edu (Per Bjornsson)
Date: Thu, 14 Jul 2005 14:16:13 -0700
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <20050714205012.GA20299@nostromo.devel.redhat.com>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
Message-ID: <1121375773.3018.25.camel@localhost.localdomain>

On Thu, 2005-07-14 at 16:50 -0400, Bill Nottingham wrote:
> Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> > If someone could please take a look at the devel branch of libifp in
> > Extras and see if it's okay wrt the new udev it would be much
> > appreciated, thanks.
> 
> It looks sane to me; I don't have the hardware to test it.

Thanks for checking. I'd say it's likely to work about as well as
gPhoto, that's where I snatched the scripts... ;) (At least it works on
FC4 as the package is now, I have tested with hardware. Of course,
devices may be missing in the mapping file so it may not work
universally.)

OK, on a more serious note, what actually drives the scripts there is
the /etc/hotplug/usb.agent, which maps devices to hotplug actions using
the various helper files (including those in /etc/hotplug/usb). Is this
still the preferred way to go about adding some custom device
initialization on hotplug?

I should perhaps note that just like the cameras accessed through
gPhoto, the music players we're talking about here are not USB mass
storage devices, they're generally accessed through userspace programs
using libusb. Thus we're not interested in making device nodes in /dev
or so, the only thing the script is supposed to do is to set up the
correct access permissions on the relevant /proc/bus/usb/* node.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From mgomes at redhat.com  Thu Jul 14 21:24:09 2005
From: mgomes at redhat.com (Mauricio Gomes)
Date: Thu, 14 Jul 2005 17:24:09 -0400
Subject: Cutting Edge
In-Reply-To: <603d1b680507141355264aec3@mail.gmail.com>
References: <603d1b680507141355264aec3@mail.gmail.com>
Message-ID: <42D6D7F9.70606@redhat.com>

OmniUni wrote:

> Looking over the recent editions of this list, I have noticed that in 
> many respects, fedora development is stuck in the past.
>
Which respects?  You only mention your personal preference of KDE.

> Fedora Core is supposed to be a cutting edge distro, and for the most 
> part, it is. As a community, however, we must not be afraid to bring 
> up new ideas to a distribution with so much a standardized history. 
> For Fedora to remain cutting edge, it must be willing to change. I am 
> a KDE user, and I am because I find it easier, faster, lighter, more 
> stable, more friendly, more cusomizable, more elegant, and more 
> powerful than GNOME. Will this change? perhaps. I used to like GNOME 
> better, but that changed when Sawfish changed to Metacity. (around RHL 
> 7.3-- 8.0 was metacity) Will requesting that Fedora become KDE based 
> instead of GNOME based be likely to make a major impact here? no. Is 
> it important that I request? yes. I do so, because it alerts the 
> developers to views of Feora Core's users. OpenSource must be about 
> Open Minds as well as free software. I am up to a lively discussion 
> about KDE vs. GNOME, and a friendly reminder that GNOME must remain 
> the focus of Fedora Core for now, but I certainly hope that I will not 
> get any responses that look down upon me for expressing my views.
>
> -OmniUni at gmail.com <mailto:OmniUni at gmail.com>

You preferring KDE over Gnome is personal opinion.  Fedora includes KDE 
and Gnome.  If a user thinks KDE is all those things you say it is, they 
can easily switch to it, or not install Gnome at all.  Selecting a 
default WM though hardly makes a distribution "cutting-edge."

Mauricio Gomes



From perbj at stanford.edu  Thu Jul 14 21:25:14 2005
From: perbj at stanford.edu (Per Bjornsson)
Date: Thu, 14 Jul 2005 14:25:14 -0700
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <1121375773.3018.25.camel@localhost.localdomain>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121375773.3018.25.camel@localhost.localdomain>
Message-ID: <1121376314.3018.27.camel@localhost.localdomain>

On Thu, 2005-07-14 at 14:16 -0700, Per Bjornsson wrote:

> Thanks for checking. I'd say it's likely to work about as well as
> gPhoto, that's where I snatched the scripts... ;) (At least it works on
> FC4 as the package is now, I have tested with hardware. Of course,
> devices may be missing in the mapping file so it may not work
> universally.)

Oops, sorry, I didn't realize that Ignacio had changed things around
already, I was looking at the wrong branch. Please ignore what I just
wrote.

Sorry,
Per




From notting at redhat.com  Thu Jul 14 21:58:30 2005
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 14 Jul 2005 17:58:30 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <1121375773.3018.25.camel@localhost.localdomain>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121375773.3018.25.camel@localhost.localdomain>
Message-ID: <20050714215830.GC24244@nostromo.devel.redhat.com>

Per Bjornsson (perbj at stanford.edu) said: 
> OK, on a more serious note, what actually drives the scripts there is
> the /etc/hotplug/usb.agent, which maps devices to hotplug actions using
> the various helper files (including those in /etc/hotplug/usb). Is this
> still the preferred way to go about adding some custom device
> initialization on hotplug?

No. In fact, /etc/hotplug/usb.agent is going away very very soon; it should
all be done via udev rules.

> using libusb. Thus we're not interested in making device nodes in /dev
> or so, the only thing the script is supposed to do is to set up the
> correct access permissions on the relevant /proc/bus/usb/* node.

That should be done easily enough - even if you're not making device nodes,
you'll still get notification of the device id being added, which should
allow you to do this.

Bill



From roland at redhat.com  Thu Jul 14 23:39:19 2005
From: roland at redhat.com (Roland McGrath)
Date: Thu, 14 Jul 2005 16:39:19 -0700 (PDT)
Subject: setitimer
In-Reply-To: divij bhatt's message of  Thursday, 14 July 2005 12:33:33 +0530
	<1121324613.5129.2.camel@localhost.localdomain>
Message-ID: <20050714233919.11EA71809FC@magilla.sf.frob.com>

>     I want to know that setitimer can be used on a per thread basis or
> not.

POSIX specifies that the setitimer clocks are per-process, not per-thread.
Linux had them per-thread until recently, but in current versions
(including FC4) it is per-process.  If you want more options for timers,
you can use timer_create and the related interfaces.



From mailman at hanez.org  Thu Jul 14 23:54:10 2005
From: mailman at hanez.org (Johannes Findeisen)
Date: Fri, 15 Jul 2005 01:54:10 +0200
Subject: Kernel panic in 2.6.11-1.35_FC3@i686
In-Reply-To: <1121238860.3383.10.camel@isz>
References: <1121213678.4720.7.camel@phantom.wg.xw3.org>
	<1121238860.3383.10.camel@isz>
Message-ID: <1121385250.4267.10.camel@phantom.wg.xw3.org>

On Wed, 2005-07-13 at 10:14 +0300, Dan Fruehauf wrote:
> On Wed, 2005-07-13 at 02:14 +0200, Johannes Findeisen wrote:
> > Hello all,
> > 
> > just got this kernel panic right after updating Fedora core 3 to
> > 2.6.11-1.35_FC3. I am running Fedora Core 3 for x86 on an AMD64 machine
> > - if this helps?. Since i have no serial console i could not copy and
> > paste the panic message, so i have made a photo which you can see at:
> > 
> > http://hanez.org/images/content/kernelpanic.jpg
> > 
> > The following package is what i am talking about: 
> > 
> > kernel-2.6.11-1.35_FC3.i686.rpm
> > 
> > Please tell me how i could debug such things better in the future. I
> > really want to understand the way developers are handling this.
> > 
> Johannes,
> This looks like your kernel is unable to mount your root filesystem.
> I'd suggest trying to re-run mkinitrd and create one suitable for your
> system.
> Before the panic you can see that initrd has troubles switching to your
> new root that perhaps wasn't mounted successfully.
> 
> I got something similar with a Xen0 kernel under VMWare while running
> with a SCSI disk. The driver wasn't loaded well and a similar panic
> followed.

Hello Dan,

sorry for replying late. I didn't had enough time the last days. I have
created a new initial ramdisc and got the same error as above.

My main confusion is: How will developers debug this issue? 

I could set up a serial console for logging debug output but is this the
right way?

I definitely not have destroyed my system because of not enough
knowledge. I have simply updated my Kernel using the graphical update
tool. Okay, i have installed many packages from other repositories but
not kernel related and i hope no system related packages... ;-)

Could someone give me a hint how i could find out what the problem is or
should i post a bugreport?

Sorry, i never have posted kernel related bugs in the last years. I am
really interested how things are handled the right way, before posting
things to bugzilla that aren't bugs, or where i can get more information
about the problem before posting?

Thanks in advance,
-- 
Johannes Findeisen



From ivazquez at ivazquez.net  Fri Jul 15 00:31:06 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Thu, 14 Jul 2005 20:31:06 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <20050714205012.GA20299@nostromo.devel.redhat.com>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
Message-ID: <1121387466.6290.20.camel@ignacio.lan>

On Thu, 2005-07-14 at 16:50 -0400, Bill Nottingham wrote:
> Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> > If someone could please take a look at the devel branch of libifp in
> > Extras and see if it's okay wrt the new udev it would be much
> > appreciated, thanks.
> 
> It looks sane to me; I don't have the hardware to test it.

It looks like the script isn't being run. How can I debug/trace udev to
see what it's doing?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050714/c1594929/attachment.sig>

From mpeters at mac.com  Fri Jul 15 00:40:05 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Thu, 14 Jul 2005 17:40:05 -0700
Subject: NetworkManager
In-Reply-To: <1121350577.14067.6.camel@dcbw.boston.redhat.com>
References: <1121343762.11210.84.camel@dimi>
	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
Message-ID: <1121388006.2665.8.camel@locolhost.localdomain>

On Thu, 2005-07-14 at 10:16 -0400, Dan Williams wrote:
> NM blows away
> your /etc/resolv.conf because it uses a local caching nameserver to deal
> with horrible glibc resolver dropouts when network switches occur.
> That's not likely to change, what may change would be the ability to add
> custom entries to the caching nameserver's config.
> 
> Dan

It should be optional - I can't use it for that reason. It needs to use
the nameserver specified by the dhcp server or I can't use it.



From jkeating at j2solutions.net  Fri Jul 15 00:56:46 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 14 Jul 2005 17:56:46 -0700
Subject: NetworkManager
In-Reply-To: <1121388006.2665.8.camel@locolhost.localdomain>
References: <1121343762.11210.84.camel@dimi>
	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
	<1121388006.2665.8.camel@locolhost.localdomain>
Message-ID: <1121389006.8029.0.camel@prometheus.gamehouse.com>

On Thu, 2005-07-14 at 17:40 -0700, Michael A. Peters wrote:
> 
> It should be optional - I can't use it for that reason. It needs to
> use
> the nameserver specified by the dhcp server or I can't use it.
> 

Won't the local caching name server look to that DHCP provided DNS
server for "upstream" dns info?

-- 
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



From danfr at matrix.co.il  Fri Jul 15 03:21:29 2005
From: danfr at matrix.co.il (Dan Fruehauf)
Date: Fri, 15 Jul 2005 06:21:29 +0300
Subject: Kernel panic in 2.6.11-1.35_FC3@i686
In-Reply-To: <1121385250.4267.10.camel@phantom.wg.xw3.org>
References: <1121213678.4720.7.camel@phantom.wg.xw3.org>
	<1121238860.3383.10.camel@isz>
	<1121385250.4267.10.camel@phantom.wg.xw3.org>
Message-ID: <1121397689.4768.7.camel@isz>

On Fri, 2005-07-15 at 01:54 +0200, Johannes Findeisen wrote:
> On Wed, 2005-07-13 at 10:14 +0300, Dan Fruehauf wrote:
> > On Wed, 2005-07-13 at 02:14 +0200, Johannes Findeisen wrote:
> > > Hello all,
> > > 
> > > just got this kernel panic right after updating Fedora core 3 to
> > > 2.6.11-1.35_FC3. I am running Fedora Core 3 for x86 on an AMD64 machine
> > > - if this helps?. Since i have no serial console i could not copy and
> > > paste the panic message, so i have made a photo which you can see at:
> > > 
> > > http://hanez.org/images/content/kernelpanic.jpg
> > > 
> > > The following package is what i am talking about: 
> > > 
> > > kernel-2.6.11-1.35_FC3.i686.rpm
> > > 
> > > Please tell me how i could debug such things better in the future. I
> > > really want to understand the way developers are handling this.
> > > 
> > Johannes,
> > This looks like your kernel is unable to mount your root filesystem.
> > I'd suggest trying to re-run mkinitrd and create one suitable for your
> > system.
> > Before the panic you can see that initrd has troubles switching to your
> > new root that perhaps wasn't mounted successfully.
> > 
> > I got something similar with a Xen0 kernel under VMWare while running
> > with a SCSI disk. The driver wasn't loaded well and a similar panic
> > followed.
> 
> Hello Dan,
> 
> sorry for replying late. I didn't had enough time the last days. I have
> created a new initial ramdisc and got the same error as above.
> 
> My main confusion is: How will developers debug this issue? 
> 
> I could set up a serial console for logging debug output but is this the
> right way?
> 
> I definitely not have destroyed my system because of not enough
> knowledge. I have simply updated my Kernel using the graphical update
> tool. Okay, i have installed many packages from other repositories but
> not kernel related and i hope no system related packages... ;-)
> 
> Could someone give me a hint how i could find out what the problem is or
> should i post a bugreport?
> 
> Sorry, i never have posted kernel related bugs in the last years. I am
> really interested how things are handled the right way, before posting
> things to bugzilla that aren't bugs, or where i can get more information
> about the problem before posting?
> 
> Thanks in advance,
> -- 
> Johannes Findeisen
> 

Jonannes,
Unfortunately I'm not a kernel developer, but even though i could give
you some guidelines.
About your specific panic - I would first try and reconfigure my initrd
and perhaps add some debug messages to it's startup script to see where
this 'mount failed' message is coming from and why...
I would suggest configuring a netdump server
(http://www.redhat.com/support/wpapers/redhat/netdump/index.html) - but
that is a little more relevant for a running, operational system which
is not what we have at this time.

So I would go with the first one - open your initrd image - see that
things are sane there, might be an initrd bug after all...
Perhaps if your initrd image isn't that big you could also post it on
the list (or at least send me it for a review).

Oh - and if you don't need initrd - try running without it :)

Regards,
-- 
Dan Fruehauf
Matrix IT, Linux Consulting



From symbiont at berlios.de  Fri Jul 15 07:19:59 2005
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 15 Jul 2005 15:19:59 +0800
Subject: NetworkManager
In-Reply-To: <1121350577.14067.6.camel@dcbw.boston.redhat.com>
References: <1121343762.11210.84.camel@dimi>
	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
Message-ID: <200507151519.59773.symbiont@berlios.de>

On Thursday 14 July 2005 22:16, Dan Williams wrote:
> NM blows away
> your /etc/resolv.conf because it uses a local caching nameserver to
> deal with horrible glibc resolver dropouts when network switches
> occur. That's not likely to change, what may change would be the
> ability to add custom entries to the caching nameserver's config.

I don't use NM yet, but I also use local DNS as well to get around this 
problem and also to add another very nice feature: Union two domains 
together.  You can't do this with resolver.  Each nameserver 
in /etc/resolv.conf needs to be a complete set that are identical to 
other.  It will not say, "hey I can't find foo in nameserver 1, so let 
me go find it in nameserver 2."

However, local DNS, can say, "hey foo is in bar.com, so i'm going to 
look up these set of forwarders that work for bar.com; for everything 
else, I'll look up these other set of forwarders".

Unioning of domains really bit me in the butt for my laptop use when 
connecting to the internet and to our corporate VPN.  By using local 
DNS, I also sculpt the packets better by not always trying to resolve 
against the VPN-provided DNS servers.

If this type of setup was added to NM, it would be very, very nice.

Anyway, just my experience with the issue. YMMV.


-- 
-jeff



From ivazquez at ivazquez.net  Fri Jul 15 07:30:35 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 15 Jul 2005 03:30:35 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <1121387466.6290.20.camel@ignacio.lan>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121387466.6290.20.camel@ignacio.lan>
Message-ID: <1121412635.6290.28.camel@ignacio.lan>

On Thu, 2005-07-14 at 20:31 -0400, Ignacio Vazquez-Abrams wrote:
> It looks like the script isn't being run. How can I debug/trace udev to
> see what it's doing?

Never mind, I found it.

*sigh*

I also discovered, upon reading the udev docs more closely, that it will
*not* work for devices that have a user-mode driver, which fries sane as
well.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/e64b35a9/attachment.sig>

From dcbw at redhat.com  Fri Jul 15 11:23:48 2005
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 15 Jul 2005 07:23:48 -0400 (EDT)
Subject: NetworkManager
In-Reply-To: <1121389006.8029.0.camel@prometheus.gamehouse.com>
References: <1121343762.11210.84.camel@dimi>
	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
	<1121388006.2665.8.camel@locolhost.localdomain>
	<1121389006.8029.0.camel@prometheus.gamehouse.com>
Message-ID: <Pine.LNX.4.58.0507150723040.5700@devserv.devel.redhat.com>



On Thu, 14 Jul 2005, Jesse Keating wrote:

> On Thu, 2005-07-14 at 17:40 -0700, Michael A. Peters wrote:
> > 
> > It should be optional - I can't use it for that reason. It needs to
> > use
> > the nameserver specified by the dhcp server or I can't use it.
> > 
> 
> Won't the local caching name server look to that DHCP provided DNS
> server for "upstream" dns info?

Exactly, NetworkManager gets the DNS server addresses via DHCP, then writes them 
to the caching-nameserver's config file.  So your local machine always talks to 
127.0.0.1, but the caching-nameserver talks to yhe real DNS servers.

Dan



From buildsys at redhat.com  Fri Jul 15 11:23:53 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 15 Jul 2005 07:23:53 -0400
Subject: rawhide report: 20050715 changes
Message-ID: <200507151123.j6FBNr71016392@porkchop.devel.redhat.com>

New package amtu
	Abstract Machine Test Utility (AMTU)


Removed package apel

Updated Packages:

aspell-bg-50:0.50-10
--------------------
* Fri Jul 15 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-10
- build with aspell-0.60.3
- convert bulgarian.kdb to utf-8

audit-0.9.19-1
--------------
* Thu Jul 14 2005 Steve Grubb <sgrubb at redhat.com> 0.9.19-1
- ausearch remove debug code

* Thu Jul 14 2005 Steve Grubb <sgrubb at redhat.com> 0.9.18-1
- auditd message formatter use MAX_AUDIT_MESSAGE_LENGTH to prevent clipping

control-center-1:2.11.5-2
-------------------------
* Thu Jul 14 2005 Matthias Clasen <mclasen at redhat.com> - 1:2.11.5-2
- Disable the about-me capplet

createrepo-0.4.3-1
------------------
* Thu Jul 14 2005 Paul Nasrat <pnasrat at redhat.com> - 0.4.3-1
- New upstream version 0.4.3 (cachedir support)

dhcp-10:3.0.3rc1-1
------------------
* Thu Jul 14 2005 Jason Vas Dias <jvdias at redhat.com> 10:3.0.3rc1-1
- Upgrade to upstream version 3.0.3rc1
- fix bug 163203: silence ISC blurb on configtest 
- fix default 'boot file server' value (packet->siaddr):
  In dhcp-3.0.2(-), this was defaulted to the server address;
  now it defaults to 0.0.0.0 (a rather silly default!) and 
  must be specified with the 'next-server' option ( not the tftp-boot-server option ?!?)
  which causes PXE boot clients to fail to load anything after the boot file.

eclipse-1:3.1.0_fc-6
--------------------
* Tue Jul 12 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-6
- Bump release to build against new gcc.
- Bump gcc requirement to gcc 4.0.1.
- Add back BuildArch until we get bootstrapping sorted out.
- Bump required version of java-gcj-compat to the latest (-40jpp_37rh).
- Remove lots of jiggery-pokery with native compilation and use gbenson's new
  aot-compile.
- Re-work files sections appropriately.
- Change mozilla-nspr-devel -> nspr-devel due to change in mozilla packaging.
- Update patch for mozilla build as per above.
- Add org.eclipse.osgi_3.1.0.jar to exclude.

* Tue Jul 05 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-5
- Revert ecj_bootstrap patch since it won't work.
- Keep mozilla requirement off ppc64.
- Add ant-apache-bsf requirement since we have that in FC5.

* Tue Jul 05 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-4
- Add ecj_bootstrap patch from Gary Benson to bootstrap new architectures.
- Remove ExclusiveArch.

eclipse-cdt-1:3.0.0_fc-0.RC2.1
------------------------------
* Thu Jul 14 2005 Andrew Overholt <overholt at redhat.com> 3.0.0_fc-0.RC2.1
- Import new upstream version (3.0RC2).
- Use gbenson's new aot-compile-rpm and change requirements appropriately.
- Re-enable native compilation - let's see what happens.

emacs-21.4-7
------------
* Thu Jul 14 2005 Jens Petersen <petersen at redhat.com> - 21.4-7
- update rpm-spec-mode.el to cvs revision 1.17 (Ville Skytt??)
  - fixes expansion of %{?dist}
- replace emacs-21.4-setarch_for_loadup-101818.patch with backport
  emacs-21-personality-linux32-101818.patch from cvs (Jan Dj??rv)
  which also turns off address randomization during dumping (Masatake Yamato)
  - no longer need to pass SETARCH to make on i386
- move ownership of /usr/share/emacs/ and /usr/share/emacs/21.4/
  from emacs to emacs-el and emacs-leim subpackages
- don't build tramp html and dvi documentation
- drop src/config.in part of bzero-and-have-stdlib.dpatch to avoid
  compiler warnings

gcc-4.0.1-3
-----------
* Thu Jul 14 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.1-3
- update from CVS
  - PRs bootstrap/21704, c++/10611, c++/20563, c++/20637, c++/20678,
	c++/20746, c++/20789, c++/21903, c++/21929, fortran/15966,
	fortran/16531, fortran/18781, fortran/22327, fortran/22417,
	libfortran/16435, libfortran/21875, libgfortran/22412,
	libstdc++/22102, middle-end/20593, tree-opt/22105
- another attempt to fix libstdc++ mt allocator (#161061,
  PR libstdc++/22309)
- diagnose invalid uses of inline (Eric Christopher, #162216, #159731,
  PRs c/22052, c/21975)
- fix linker command line ordering when compiling multiple
  java source files (Tom Tromey, #163099)
- use backtrace () in libgcj even on ia64
- support more than 16 nested GCC visibility pragmas (H.J.Lu)

hotplug-3:2004_09_23-8
----------------------
* Thu Jul 14 2005 Bill Nottingham <notting at redhat.com> 3:2004_09_23-8
- remove pci*, usb* in favor of udev

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_38rh
------------------------------------------
* Thu Jul 14 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_38rh
- Import java-gcj-compat 1.0.33.

kernel-2.6.12-1.1433_FC5
------------------------
* Thu Jul 14 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git1

libsepol-1.7.3-1
----------------
* Thu Jul 14 2005 Dan Walsh <dwalsh at redhat.com> 1.7.3-1
- Upgrade to latest from NSA
	* Merged header file cleanup and memory leak fix from Ivan Gyurdiev (Red Hat).
	* Merged genbools debugging message cleanup from Red Hat.

pam-0.80-1
----------
* Thu Jul 14 2005 Tomas Mraz <tmraz at redhat.com> 0.80-1
- upgrade to new upstream sources
- removed obsolete patches
- pam_selinux module shouldn't fail on broken configs unless
  policy is set to enforcing (Dan Walsh)

* Tue Jun 21 2005 Tomas Mraz <tmraz at redhat.com> 0.79-11
- update pam audit patch
- add support for new limits in kernel-2.6.12 (#157050)

rarpd-ss981107-21
-----------------
* Thu Jul 14 2005 Phil Knirsch <pknirsch at redhat.com> ss981107-21
- Fix for leak socket descriptors (#162000)

selinux-policy-strict-1.25.2-5
------------------------------
* Thu Jul 14 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-5
- Fixup cyrus to read mail spool
- Fix vpnc.te, NetworkManager and others for strict policy
- Add isakmp port

selinux-policy-targeted-1.25.2-5
--------------------------------
* Thu Jul 14 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-5
- Fixup cyrus to read mail spool
- Fix vpnc.te, NetworkManager and others for strict policy
- Add isakmp port

sqlite-3.2.2-1
--------------
* Fri Jul 08 2005 Roland McGrath <roland at redhat.com> - 3.2.2-1
- Upgrade to 3.2.2 release.

tcpdump-14:3.9.1-1
------------------
* Thu Jul 14 2005 Martin Stransky <stransky at redhat.com> - 14:3.9.1-1
- New upstream version

uucp-1.07-10
------------
* Thu Jul 14 2005 Peter Vrabec <pvrabec at redhat.com> 1.07-10
- revert fix from 1.07-9
- fix truncation of values on 32b platforms where statvfs64
  is being called on a large file system (#153259)

vnc-4.1.1-14
------------
* Thu Jul 14 2005 Tim Waugh <twaugh at redhat.com> 4.1.1-14
- Pulled RENDER support altogether.  It can cause Xvnc to get into a busy
  loop somehow.

* Wed Jul 13 2005 Tim Waugh <twaugh at redhat.com> 4.1.1-13
- RENDER clipping fix from Mark McLoughlin.

Broken deps for s390
----------------------------------------------------------
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	ethereal - 0.10.11-3.s390 requires libpcap.so.0.8.3
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_38rh.s390 requires gjdoc
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	ethereal-gnome - 0.10.11-3.s390 requires libpcap.so.0.8.3
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	mozilla-nss - 37:1.7.8-3.s390 requires mozilla-nspr = 37:1.7.8-3
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	ppp - 2.4.2-7.s390 requires libpcap.so.0.8.3
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for ppc
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.2-7.ppc requires libpcap.so.0.8.3
	isdn4k-utils - 3.2-29.ppc requires libpcap.so.0.8.3
	ethereal - 0.10.11-3.ppc requires libpcap.so.0.8.3
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-3.ppc requires libpcap.so.0.8.3
	mozilla-nss - 37:1.7.8-3.ppc requires mozilla-nspr = 37:1.7.8-3
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16



Broken deps for ppc64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-3.ppc64 requires libpcap.so.0.8.3()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	firstboot - 1.3.43-1.noarch requires system-config-display
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	ethereal - 0.10.11-3.ppc64 requires libpcap.so.0.8.3()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_38rh.ppc64 requires gjdoc
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	isdn4k-utils - 3.2-29.ppc64 requires libpcap.so.0.8.3()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	ppp - 2.4.2-7.ppc64 requires libpcap.so.0.8.3()(64bit)
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging



Broken deps for s390x
----------------------------------------------------------
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_38rh.s390x requires gjdoc
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	mozilla-nss - 37:1.7.8-3.s390 requires mozilla-nspr = 37:1.7.8-3
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	ppp - 2.4.2-7.s390x requires libpcap.so.0.8.3()(64bit)
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	ethereal - 0.10.11-3.s390x requires libpcap.so.0.8.3()(64bit)
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	ethereal-gnome - 0.10.11-3.s390x requires libpcap.so.0.8.3()(64bit)
	mozilla-nss - 37:1.7.8-3.s390x requires mozilla-nspr = 37:1.7.8-3
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	mozilla-nss - 37:1.7.8-3.i386 requires mozilla-nspr = 37:1.7.8-3
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-3.x86_64 requires libpcap.so.0.8.3()(64bit)
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-3.x86_64 requires libpcap.so.0.8.3()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.x86_64 requires libpcap.so.0.8.3()(64bit)
	mozilla-nss - 37:1.7.8-3.x86_64 requires mozilla-nspr = 37:1.7.8-3
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	ppp - 2.4.2-7.x86_64 requires libpcap.so.0.8.3()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for i386
----------------------------------------------------------
	ppp - 2.4.2-7.i386 requires libpcap.so.0.8.3
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-3.i386 requires libpcap.so.0.8.3
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal - 0.10.11-3.i386 requires libpcap.so.0.8.3
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	mozilla-nss - 37:1.7.8-3.i386 requires mozilla-nspr = 37:1.7.8-3
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.i386 requires libpcap.so.0.8.3
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	ethereal-gnome - 0.10.11-3.ia64 requires libpcap.so.0.8.3()(64bit)
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	isdn4k-utils - 3.2-29.ia64 requires libpcap.so.0.8.3()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	p6spy - 1.3-2jpp_1fc.noarch requires regexp
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	mozilla-nss - 37:1.7.8-3.ia64 requires mozilla-nspr = 37:1.7.8-3
	bcel - 5.1-1jpp_4fc.noarch requires regexp
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp
	java-1.4.2-gcj-compat - 1.4.2.0-40jpp_38rh.ia64 requires gjdoc
	ppp - 2.4.2-7.ia64 requires libpcap.so.0.8.3()(64bit)
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	castor - 0.9.5-1jpp_1fc.noarch requires regexp
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires ant >= 0:1.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-logging >= 0:1.0.4
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jonas - 4.3.3-1jpp_5fc.noarch requires regexp
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	rgmanager - 1.9.31-3.ia64 requires ccs
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging
	jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires regexp
	axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	ethereal - 0.10.11-3.ia64 requires libpcap.so.0.8.3()(64bit)





From walters at redhat.com  Fri Jul 15 12:29:12 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 08:29:12 -0400
Subject: NetworkManager
In-Reply-To: <200507151519.59773.symbiont@berlios.de>
References: <1121343762.11210.84.camel@dimi>
	<53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
	<200507151519.59773.symbiont@berlios.de>
Message-ID: <1121430552.10494.3.camel@nexus.verbum.private>

On Fri, 2005-07-15 at 15:19 +0800, Jeff Pitman wrote:

> If this type of setup was added to NM, it would be very, very nice.

That type of usage is one of the major reasons why we chose to use bind
for NetworkManager.  I'm not sure if NetworkManager's VPN support takes
advantage of it yet, but it could if it doesn't.




From dimi at lattica.com  Fri Jul 15 12:43:52 2005
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 15 Jul 2005 08:43:52 -0400
Subject: NetworkManager
References: <1121343762.11210.84.camel@dimi><53621.68.254.239.135.1121347159.squirrel@ausil.us>
	<1121350577.14067.6.camel@dcbw.boston.redhat.com>
Message-ID: <047f01c5893a$db7ce0f0$b6491b31@td612671>

From: "Dan Williams" <dcbw at redhat.com>

> It does work with any static IP address you have configured with
> system-config-network.  It will apply the IP & DNS configuration you've
> selected using system-config-network Profiles on startup.  NM blows away
> your /etc/resolv.conf because it uses a local caching nameserver to deal
> with horrible glibc resolver dropouts when network switches occur.
> That's not likely to change, what may change would be the ability to add
> custom entries to the caching nameserver's config.

That's fine, but the current behaviour is rather brutal: you start it and
everything stops working. That can't be good.

At the very least can you back-up resolv.conf, and maybe restore it when
you shut NM down? I guess that can happen even in the init.d script.

Ideally, NM should migrate the content of resolv.conf to bind, so that
starting/stopping NM becomes seemless. Also a more explanatory message
in the overriden resolv.conf would be appreciated.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From gareth.foster at siemens.com  Fri Jul 15 12:58:29 2005
From: gareth.foster at siemens.com (Foster, Gareth)
Date: Fri, 15 Jul 2005 13:58:29 +0100
Subject: /usr and /usr/local
Message-ID: <CC9F48B022FA5B46A295029EA3F713A60233EC8E@ntht205e.siemenscomms.co.uk>

Hello list,

I have been working on porting my wallpaper tray program to the gnome panel
(from the notification area), and I have hit a snag with Fedora.

I have to configure my program as follows:

./configure --prefix="/usr"

The default is /usr/local, and this results in my panel applet not being
available from the menu. Now, I am trying to add a gconf schema (I think not
having one was causing bugs), and the schema is ending up getting installed
to /usr/etc which is clearly wrong.

Apparently I don't have to configure like this on other distros, so what can
I do to get around the problem?

Regards,

Gaz


**********************************************
*  http://www.mozilla.org/products/firefox/  *
**********************************************



From rhl-devel-list at lnx.ro  Fri Jul 15 13:06:35 2005
From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu)
Date: Fri, 15 Jul 2005 16:06:35 +0300
Subject: /usr and /usr/local
In-Reply-To: <CC9F48B022FA5B46A295029EA3F713A60233EC8E@ntht205e.siemenscomms.co.uk>
References: <CC9F48B022FA5B46A295029EA3F713A60233EC8E@ntht205e.siemenscomms.co.uk>
Message-ID: <1121432795.4223.4.camel@localhost>

?n data de Vi, 15-07-2005 la 13:58 +0100, Foster, Gareth a scris:
> I have to configure my program as follows:
> 
> ./configure --prefix="/usr"
> 
> The default is /usr/local, and this results in my panel applet not being
> available from the menu. Now, I am trying to add a gconf schema (I think not
> having one was causing bugs), and the schema is ending up getting installed
> to /usr/etc which is clearly wrong.
> 
> Apparently I don't have to configure like this on other distros, so what can
> I do to get around the problem?


./configure --prefix=/usr --sysconfdir=/etc

-- 
Cioby




From mattdm at mattdm.org  Fri Jul 15 13:08:24 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 15 Jul 2005 09:08:24 -0400
Subject: /usr and /usr/local
In-Reply-To: <CC9F48B022FA5B46A295029EA3F713A60233EC8E@ntht205e.siemenscomms.co.uk>
References: <CC9F48B022FA5B46A295029EA3F713A60233EC8E@ntht205e.siemenscomms.co.uk>
Message-ID: <20050715130824.GA22074@jadzia.bu.edu>

On Fri, Jul 15, 2005 at 01:58:29PM +0100, Foster, Gareth wrote:
> I have been working on porting my wallpaper tray program to the gnome panel
> (from the notification area), and I have hit a snag with Fedora.
> I have to configure my program as follows:
> ./configure --prefix="/usr"

Are you making an RPM, or just installing locally? For installing locally,
you *want* it to be going into /usr/local.


> The default is /usr/local, and this results in my panel applet not being
> available from the menu. Now, I am trying to add a gconf schema (I think not
> having one was causing bugs), and the schema is ending up getting installed
> to /usr/etc which is clearly wrong.

Try "./configure --prefix=/usr --sysconfdir=/etc". Or, if this is inside an
RPM spec file, use "%configure". (Run "rpm --eval '%configure'" from the
command line to find out what all that sets.)

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.



From dr at cluenet.de  Fri Jul 15 14:03:54 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 16:03:54 +0200
Subject: No more right click terminal
In-Reply-To: <1121344610.11210.99.camel@dimi>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
Message-ID: <20050715140354.GB10161@srv01.cluenet.de>

On Thu, Jul 14, 2005 at 08:36:50AM -0400, Dimi Paun wrote:
> On Thu, 2005-07-14 at 08:11 -0400, Jeff Spaleta wrote:
> > Debating the worth of any particular study,
> > here.. is pointless..
> 
> Very smart. It seems that _anything_ is pointless to discuss here.

Indeed. It's still all "what Red Hat likes", and screw the rest. At
least that's my (oh, not really only mine) impression.

Just look at what random stuff is thrown into core by Red Hat folks,
whereas outsiders with really useful additions are sent off to Extras.

> As I understand it, the entire point of having a _community_ distro like
> Fedora is to channel all this customer feedback into a better product.

There is no community distro. As Rahul wrote it very explicitly:

"whatever is shipped in Core is the way Red Hat wants it to be."

And http://www.fedora.redhat.com/about/ says:

"Red Hat will retain editorial control over The Fedora Project"

A community distro is something different. I'm not saying that this is
necessarily better, see Debian.

My impression of Fedora is, that it's basically the replacement for the
former Red Hat Beta Team... getting testing of new and cool stuff to put
into RHEL when it's mature enough.

> Please stop with the 'pointless' comments already, they are not helpful.

Yeah, this "if you don't agree with us, shut up and go away"
communication especially by Rahul and Jeff Spaleta really doesn't
encourage putting ANY amount of work (and discussion developements of
Fedora IS work) into Fedora anymore.

The "we follow upstream!" mantra is also only followed when it's
fitting. If the Fedora heads like a change, it gets done (see all the
custom patches that regularily pop up in packages), and if outsiders
request changes that Fedora heads don't like, we'll hear a "shut up and
go upstream, we follow upstream, basta".

I just happen to hope that things don't get worse anymore and to look
even harder for alternatives. When having done so when I had to make
a decision wether to go from FC1 to FC4 or to something else (because of
too short security fix support cycle), I didn't see any alternatives
that suck less. :-|

The terminal launch option now disappearing completely out of immediate
reach is a major blow, once again. I really wonder where this is
heading. The last really usable desktop for me was GNOME/Enlightenment
in RH 6.2 (and 7.x, but I had that only at work place and dunno how much
effort the IT folks there had put into making it work). Later on, things
got dumbed down more and more. Now we are at metacity (I call it
mediocracy) and people still keep on removing features etc. I wonder
when will install twm or fvwm again as "powerful, feature-rich"
replacement for the hello_world that metacity is. Sigh.

But that's just me I guess (probably sounding arrogant again to people
not able to handle criticism). I wait for the "shut up and go away if
you don't like what you do" comments from the usual suspects.

There are already enough distros out there trying to replicate the
uglyness of a colorful useless desktop like MS Windows. We don't need
another one. The RHEL corporate desktop users are prolly the target of
what's going on here, but I can only speculate.

Don't get me wrong. I cannot complain - it all comes for free, I greatly
respect that and am grateful for the chance to run an OS which mostly
fits my needs for zarro bucks and the source comes with it too so I can
fiddle with it if I REALLY need to. It just sucks to always here the
fairy tale of the "community" distro Fedora is supposed to be, and all
I can see is quite the contrary (except of course if it comes to offload
the boring stuff like maintaining older releases [Fedora Legacy],
betatesting new random stuff put into Core etc.).


Regards,
Daniel (now prolly being added to a lot of troll filters)

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From sundaram at redhat.com  Fri Jul 15 14:09:34 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 15 Jul 2005 19:39:34 +0530
Subject: No more right click terminal
In-Reply-To: <20050715140354.GB10161@srv01.cluenet.de>
References: <1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
Message-ID: <42D7C39E.9080607@redhat.com>

Hi

>  
>
>>As I understand it, the entire point of having a _community_ distro like
>>Fedora is to channel all this customer feedback into a better product.
>>    
>>
>
>There is no community distro. As Rahul wrote it very explicitly:
>
>"whatever is shipped in Core is the way Red Hat wants it to be."
>
>  
>
In context please. 
https://www.redhat.com/archives/fedora-devel-list/2005-June/msg01210.html


>Yeah, this "if you don't agree with us, shut up and go away"
>communication especially by Rahul and Jeff Spaleta really doesn't
>encourage putting ANY amount of work (and discussion developements of
>Fedora IS work) into Fedora anymore.
>  
>
If its development discussion, I would love to see more of them. 
Unfortunately these discussions here arent any of that now

regards
Rahul



From jspaleta at gmail.com  Fri Jul 15 15:09:26 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 11:09:26 -0400
Subject: No more right click terminal
In-Reply-To: <20050715140354.GB10161@srv01.cluenet.de>
References: <1121248417.16074.19.camel@goose>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
Message-ID: <604aa791050715080950042ef5@mail.gmail.com>

On 7/15/05, Daniel Roesen <dr at cluenet.de> wrote:
> The "we follow upstream!" mantra is also only followed when it's
> fitting. 

Indeed, there are several people who maintain and help develop Core
components. Those people all make judgement calls as to when its
appropriate to break from upstream.  Its not worthwhile to point out
that the policy of following upstream is not strictly enforced across
the whole distribution.  There is no strict policy...there is intent.
>From component to component i think its pretty clear which developers
are most intent on following upstream and which are more willing to
bend a little.  In most cases with regard to gnome, like the issues
brought up in this thread, its pretty clear the the developers and
package maintainers are intent on following gnome upstream as much as
possible.  The result of that intent.. is that concerns about
viability and usefulness of the gnome defaults need to be discussed as
part of ongoing gnome development if you want to maximize the
potential impact of your opinions.  If your goal is to minimize the
impact of your opinions and arguments... continue to discuss them
downstream.  I can't fathom why someone would choose to minimize
rather than maximize their impact with regard to an issue they care
enough about to spend time commenting on in a mailinglist.


> When having done so when I had to make
> a decision wether to go from FC1 to FC4 or to something else (because of
> too short security fix support cycle), I didn't see any alternatives
> that suck less. :-|

There's a tagline for marketting. "Fedora: garunteed to suck less than
other alternatives"
If you'd like to discuss more ideas for fedora marketting taglines,
there is a mailinglist dedicated for fedora marketting.

> 
> The terminal launch option now disappearing completely out of immediate
> reach is a major blow, once again. I really wonder where this is
> heading. 

No need to wonder... If you get invovled or at least follow gnome
development discussions upstream.. I'm sure you can get a clearer
picture of project direction and momentum.

> I wonder
> when will install twm or fvwm again as "powerful, feature-rich"
> replacement for the hello_world that metacity is. Sigh.

twm is still provided in Core and I still use fvwm in some situations.
 I accept the fact that metacity is not necessarily the best fit for
all situations. I also accept the fact that default choices have to be
made with a target group of users in mind. I also accept that its
realistically when defaults have to be chosen the defaults will not be
perfect for all users.
If you can't accept these statements as fact, you're head is in the
wrong space and you are going to be continually frustrated by the
gnome design process.  I accept the choice of upstream gnome to have
metacity as the default window manager even though it does not suit me
personally in all situations.  I do not feel its worth arguing over
defaults simply because my personal needs are not met with the default
settings, as long as its "easy enough" to re-configure.  I don't
personally need the defaults to fit me perfectly, but I need to be
able to re-configure it, and I desire for that re-configuration to
meet a minimum standard of ease.

In the case of the terminal menu item, its already been pointed out
that people are working on packaging it up as an addon for Fedora
Extras. And I'm sure fvwm can find a home in Extras if a willing
contributor wants to package it.  In terms of re-configuration of
gnome on a fedora system to move from defaults to "power-user"
configs, I'm pretty sure there is a path forward through the sabayon
project, which is in extras for fc4.


> I wait for the "shut up and go away if
> you don't like what you do" comments from the usual suspects.

Your complaints seem to me more about gnome defaults than anything
fedora specific.
Since gnome defaults impact more than just fedora, you should take
your concerns to the gnome project directly in order to maximize the
impact you will have across a number of distributions that provide a
gnome desktop experience, potentially making alternatives to fedora
"suck less" for you as well.

-jef


-jef"i think someone is mistaking assuming i work for sombrero rojo"spaleta



From andy at warmcat.com  Fri Jul 15 15:29:04 2005
From: andy at warmcat.com (Andy Green)
Date: Fri, 15 Jul 2005 16:29:04 +0100
Subject: No more right click terminal
In-Reply-To: <604aa791050715080950042ef5@mail.gmail.com>
References: <1121248417.16074.19.camel@goose>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
Message-ID: <42D7D640.6020607@warmcat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Spaleta wrote:

| impact of your opinions and arguments... continue to discuss them
| downstream.  I can't fathom why someone would choose to minimize
| rather than maximize their impact with regard to an issue they care
| enough about to spend time commenting on in a mailinglist.

I can answer this.  By installing Fedora people are asserting a choice
in "downstream" terms.  They understand that RHAT has some flexibility
in terms of overrides (patches) of upstream providers.  Therefore it
makes more sense to them to try to get the relatively familiar RHAT
buy-in of what they want than to do battle in the completely unfamilar
upstream microclimate.  Naturally I see your point too, but I also see
bearded fundamentalists in the Gnome world.

Although I don't use Gnome as a desktop, I use enough Gnome apps to be
constantly reminded of the ineffective choices (Ctrl-L... if you can
magically find out about it -- it's not on the dialog -- then make
coffee while it tries to populate /usr/bin) foisted on folks via File
Open dialogs for example.  It seems to me there is a genuine problem
with the trend of Gnome development and the use of changing defaults to
try to program their users. They could be more modest and provide
compatability with conventional expectations as the default, and a
simple choice into the new methods.  If the new methods rock, they will
be taken up by word of mouth and become default by demand.

| If you'd like to discuss more ideas for fedora marketting taglines,
| there is a mailinglist dedicated for fedora marketting.

Well despite taking your point that upstream has more power over the
direction of upstream, some care needs to be taken not to blow off
genuine observations.  The power of RHAT to patch its desires into
reality is real, as we see in the kernel.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC19ZAjKeDCxMJCTIRAhxdAKCOdilYC9KqAeei9TPDcdAsG47xggCfSZfO
9A8yu6i5KloTJvBJQ1e0UJw=
=vYY+
-----END PGP SIGNATURE-----



From dimi at lattica.com  Fri Jul 15 15:30:21 2005
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 15 Jul 2005 11:30:21 -0400
Subject: No more right click terminal
References: <1121248417.16074.19.camel@goose><1121272795.13335.18.camel@localhost.localdomain><1121282867.21244.27.camel@rousalka.dyndns.org><42D5743A.6010300@shahms.com><1121287685.28486.18.camel@rousalka.dyndns.org><604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque><604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi><20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
Message-ID: <04c301c58952$1d086460$b6491b31@td612671>

From: "Jeff Spaleta" <jspaleta at gmail.com>
> No need to wonder... If you get invovled or at least follow gnome
> development discussions upstream.. I'm sure you can get a clearer
> picture of project direction and momentum.

This is just a 'nice' way to say to someone to fsck off, while
giving you the warm and fuzzies that you're doing a good deed.

Who do you think has the time and bandwidth to follow 50 high
traffic mailing lists? I follow a few thank you very much, and
I'm already overloaded in emails. I'm easily in the top 5% in
terms of following discussions on OSS projects, and I don't cover
even a fraction of the software I use. Which means that 95% of
our user base simply can not be expected to follow vast amounts
of discussions over hundreds of mailing lists. Not to mention that
even if they do, their chances of influencing anything are close
to zero (as we've already seen so many "do it yourself if you 
don't like it, it's pointless to complain" comments around here).

A small fraction of the 95% are complaining where it's more
convenient for them. There are obviously a lot of people on
this list that are deeply involved with a lot of projects people
care about. The smart thing to do would be for these people to
not ignore the complaints, and instead condense and relay
the sentiments expressed here to said projects.

Asking someone in a condescending tone to follow a 200-emails/day
list to have a say in about 1 decision a year that they care
about is just aggravating. For everybody. Please don't tell me
you think you are being helpful.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dr at cluenet.de  Fri Jul 15 15:50:10 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 17:50:10 +0200
Subject: No more right click terminal
In-Reply-To: <42D66111.6070202@cornell.edu>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<42D5A34D.5060307@tlarson.com> <42D66111.6070202@cornell.edu>
Message-ID: <20050715155010.GC10161@srv01.cluenet.de>

On Thu, Jul 14, 2005 at 08:56:49AM -0400, Paul A Houle wrote:
>    There are three things I use Gnome for
> 
> * launching terminals
> * shutting the computer down
> * setting the audio volume

Add to that: opening a lot of terminals on several virtual desktops
upon login, and displaying the Psi notification icon... ah... and
the clock.

Let's see when the clock will be removed "Oh you can conveniently find
it in Applcations => Tools => Tiny => What you always need => Clock"
and automatically opening terminals is blocked as "you stupid people
should use graphical applications, not shells!"

>    Open Office?  Evolution?  Give me a break.  I'd personally be happy 
> with a radically simplified interface:  a button to launch a terminal,  
> a button to shut the computer down,  and a slider to adjust audio volume.

I have nothing against features being available. They should be there
when needed. But they must not stand in the way to work EFFECTIVELY.
And removing things like handy terminal starter IS counter-productive
for almost anyone.

But we are supposed to subscribe to some more a couple hundred postings
per day mailing lists to argue about it as our distribution vendor who
is THERE to fit the rough pieces together so they make actual SENSE
doesn't care. Except of course for things like a custom desktop
background. That's important and a necessary deviation from upstream.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From notting at redhat.com  Fri Jul 15 15:52:26 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 15 Jul 2005 11:52:26 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <1121412635.6290.28.camel@ignacio.lan>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121387466.6290.20.camel@ignacio.lan>
	<1121412635.6290.28.camel@ignacio.lan>
Message-ID: <20050715155226.GA32637@nostromo.devel.redhat.com>

Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> Never mind, I found it.
> 
> *sigh*
> 
> I also discovered, upon reading the udev docs more closely, that it will
> *not* work for devices that have a user-mode driver, which fries sane as
> well.

Why wouldn't it? It's getting the same hotplug events.

Bill



From dr at cluenet.de  Fri Jul 15 16:00:26 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 18:00:26 +0200
Subject: No more right click terminal
In-Reply-To: <1121274056.10565.15.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
Message-ID: <20050715160026.GD10161@srv01.cluenet.de>

On Wed, Jul 13, 2005 at 01:00:56PM -0400, Colin Walters wrote:
> It's not about making them harder to access; it's simply removing things
> that are only useful for developers and system administrators from the
> core desktop.  Historically a large part of GNOME's audience was
> developers and system administrators, because that was the vast majority
> of the Linux user audience, but the point is we want to change that.

No, you want to change GNOME to fit for a stereotype of "non-developer,
non-admin" who you THINK is totally scared by a command line prompt.

Really, nowadays I have no real time anymore to develop software, nor to
waste my time with tuning and fiddling with system administration. My
servers, desktops and laptop are TOOLS to work on OTHER stuff. I just
want them to work. And guess what, I _NEVER_ ever use this whole
graphic filesystem browser (nautilus it's called IIRC). Before someone
even clicked thru the hierarchy, I've already _completed_ the whole task
in the shell.

Stop designing for the average windows dumbed-down user. KDE already
does this. We need good alternatives, no "just another Windows, with
another name".

> Think of it this way: what if GNOME's historical audience had been
> musicians?  Then the right click menu might have had 
> "Open Musical Score Composer".  Having that makes as much sense to the
> general population as "Open Terminal" does.

Wrong. The shell is integral with doing file system operations (and
frankly, this is NOT just admin/developer task) in a very effective and
quick way.

> With respect to the interface changing; that's true, but it seems to me
> that the GNOME/Fedora interface has been changing substantially in other
> ways (e.g. panel revamp from FC2->FC3) that the "Open Terminal" is just
> a relatively small part of it.

Given that you now see "revolt", perhaps start thinking about the
possibility that the other stuff didn't affect most users that much.

Might it be possible that your picture of the user is wrong? Could you
accept the idea that a typical user uses 100 times more often the "Open
Terminal" than ANY of the panel menus?


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dimi at lattica.com  Fri Jul 15 16:02:17 2005
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 15 Jul 2005 12:02:17 -0400
Subject: No more right click terminal
References: <1121143049.3521.16.camel@localhost.localdomain><1121245649.12224.28.camel@localhost.localdomain><1121248417.16074.19.camel@goose><55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org><1121272795.13335.18.camel@localhost.localdomain><1121282867.21244.27.camel@rousalka.dyndns.org><42D5743A.6010300@shahms.com><1121287685.28486.18.camel@rousalka.dyndns.org><42D5A34D.5060307@tlarson.com>
	<42D66111.6070202@cornell.edu>
	<20050715155010.GC10161@srv01.cluenet.de>
Message-ID: <04ee01c58956$92df07d0$b6491b31@td612671>

From: "Daniel Roesen" <dr at cluenet.de>
> Let's see when the clock will be removed "Oh you can conveniently find
> it in Applcations => Tools => Tiny => What you always need => Clock"
> and automatically opening terminals is blocked as "you stupid people
> should use graphical applications, not shells!"

As people have already helpfully pointed out, this is being packaged for
Extras. It will be a simple:
  <open terminal>   # oops, no longer exists on the menu
  RedHat => System Tools .. ehh ... => Terminal
  # su 
  $ yum install ...  # oops, install what?
  RedHat => Internet => Firefox
  Google, for ... what?
  <30 minutes later>
  Found it!
  Back to terminal
  yum install obscure-package-name-1.0.i386.rpm
  y
  <where did it go>
  <hunt for it in the menus>
  Got it!

Brilliant.

On the flip side, now the code is a lot cleaner.
Which a number of good usability studies have 
shown to be the most looked for feature by average
newbie users.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From jspaleta at gmail.com  Fri Jul 15 16:03:59 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 12:03:59 -0400
Subject: No more right click terminal
In-Reply-To: <42D7D640.6020607@warmcat.com>
References: <1121248417.16074.19.camel@goose> <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
	<42D7D640.6020607@warmcat.com>
Message-ID: <604aa79105071509037054f9f1@mail.gmail.com>

On 7/15/05, Andy Green <andy at warmcat.com> wrote:
> They understand that RHAT has some flexibility
> in terms of overrides (patches) of upstream providers.

And when they bring it up with regard to gnome desktop functionality,
they are repeatedly told to move discussion upstream. The issue isn't
that people, start the discussion here.. the issue is people (people
who know better) refuse to move the discussion upstream once they are
told it would be more effective to discuss this upstream.  As the move
from bluecurve to clearlooks illustrates there appears to be a
concerted effort by the gnome maintainers to move closer to upstream
not to further pull away from it.

> Although I don't use Gnome as a desktop, I use enough Gnome apps to be
> constantly reminded of the ineffective choices (Ctrl-L... if you can
> magically find out about it -- it's not on the dialog -- then make
> coffee while it tries to populate /usr/bin) foisted on folks via File
> Open dialogs for example.  It seems to me there is a genuine problem
> with the trend of Gnome development and the use of changing defaults to
> try to program their users. They could be more modest and provide
> compatability with conventional expectations as the default, and a
> simple choice into the new methods.  If the new methods rock, they will
> be taken up by word of mouth and become default by demand.

All of this, are comments on gnome's process for introducing and
laying out features. Without  making a judgement as to whether or not
your concerns are valid, these would be more effectively expressed as
part of upstream gnome discussions or in the case of the keyboard
shortcuts, rfes into upstream bugzilla.

> Well despite taking your point that upstream has more power over the
> direction of upstream, some care needs to be taken not to blow off
> genuine observations.  The power of RHAT to patch its desires into
> reality is real, as we see in the kernel.

No one has blown off the observations with regard to the specific
issue of terminal menu item. Clark chimed in very early on with
upstream information concerning how the terminal menu item is being
re-implemented as an addon. People took that information and are now
starting the packaging of that addon for Extras.
 
But this thread degraded into general comments about how gnome is
making upstream decisions, about how gnome has become a "social
experiement" on users. Even YOU just now decided it was worthwhile to
make a comment about how upstream gnome is changing defaults and how
you think they should be doing it.  These sorts of comments don't need
to be discussed here.. in fact they will get lost in the noise and
never make it back to gnome.
To quote you again:
"It seems to me there is a genuine problem with the trend of Gnome
development and the use of changing defaults to try to program their
users."

In no way shape or form is a comment about the "trend of gnome
development" worthwhile to discuss in fedora-devel. Comments like
these only serve to frustrate list participants, because comments
about the general trends in gnome development made in this list are
not going to lead to any changes into how gnome does things.   If you
want to make a comment about "general trends" of ANY upstream
project.. take it to the upstream project.

> Well despite taking your point that upstream has more power over the
> direction of upstream, some care needs to be taken not to blow off
> genuine observations.  The power of RHAT to patch its desires into
> reality is real, as we see in the kernel.

Its a huge logical fallacy to hold up what goes on with kernel
development as an example of whats going on with desktop application
development... inside redhat or even upstream.
What the fedora kernel people think is appropriate in terms of
patching the kernel.. is immaterial to what the desktop people think
is appropriate in terms of patching gnome functionality. There are no
parallels nor conclusions worth drawing in that comparison.


-jef



From sundaram at redhat.com  Fri Jul 15 16:06:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 15 Jul 2005 21:36:58 +0530
Subject: No more right click terminal
In-Reply-To: <04c301c58952$1d086460$b6491b31@td612671>
References: <1121248417.16074.19.camel@goose><1121272795.13335.18.camel@localhost.localdomain><1121282867.21244.27.camel@rousalka.dyndns.org><42D5743A.6010300@shahms.com><1121287685.28486.18.camel@rousalka.dyndns.org><604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque><604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi><20050715140354.GB10161@srv01.cluenet.de>	<604aa791050715080950042ef5@mail.gmail.com>
	<04c301c58952$1d086460$b6491b31@td612671>
Message-ID: <42D7DF22.8020309@redhat.com>

Hi

>Asking someone in a condescending tone to follow a 200-emails/day
>list to have a say in about 1 decision a year that they care
>about is just aggravating. For everybody. Please don't tell me
>you think you are being helpful.
>  
>

I see GNOME project making hundreds of discussions. I am pretty sure 
many people dont agree with all of them including myself. There is no 
real way to form  consensus for every such decision. If end users  start 
flaming the Fedora development list because upstream project decisions 
isnt why they personally prefer, it isnt really constructive. It doesnt 
really have to be a personal crusade.

Sure distributions have had patches and such middle man work is 
sometimes useful. A good example of this is probably packages such as 
cdrecord but in general we have to avoid doing that since its a 
*/maintenance/* 
<http://www.google.co.in/search?hl=en&hs=ZjR&client=firefox&rls=org.mozilla:en-US:unofficial&q=maintenance&spell=1>  
issue  So instead of distributions patches in extensively we have things 
like poppler ( Xpdf fork as a freedesktop.org project) being shared 
across vendors, developers and desktop environments.

In any community oriented distribution, the package 
developers/maintenancers make the decisions because they are the ones 
who are putting all the efforts into it.  Thats the general trend I see 
here. There is nothing religious or  Fedora specific about this. If you 
dont agree with me, as an experiment, pick any distribution that you 
think is more community focussed and insist on preference that the 
command line option be adopted back as patches. The only real way to get 
work done is to participate in the process.

For the GNOME terminal option  the following good ideas  have come up so 
far within the discussions.

* Setup a good default short cut for the terminal. Power users can 
launch this easily
* Have the GNOME power tools available here  
http://live.gnome.org/PowerUserTools including nautilus-open-terminal 
packaged for Fedora Extras
* Setup sabayon profiles for administrators  to deploy such changes in a 
large number of systems easily

Lets focus our efforts more on that.

regards
Rahul



From jspaleta at gmail.com  Fri Jul 15 16:10:24 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 12:10:24 -0400
Subject: No more right click terminal
In-Reply-To: <04c301c58952$1d086460$b6491b31@td612671>
References: <1121248417.16074.19.camel@goose> <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
	<04c301c58952$1d086460$b6491b31@td612671>
Message-ID: <604aa79105071509103392047d@mail.gmail.com>

On 7/15/05, Dimi Paun <dimi at lattica.com> wrote:
> Who do you think has the time and bandwidth to follow 50 high
> traffic mailing lists? 

Noone... including the GNOME DEVELOPERS. so if you want to impact
gnome development you find the lists where they discuss gnome
development.. and you talk with them there.  This isnt that list. 
fedora development list is not the place to contructively talk about
"general trends" in gnome development... nor is it the place to
constructively discuss whether or not gnome has turned into a "social
experiment."  These are issue that must be brought to the attention of
the upstream project.

I'm beginning to think you don't really have a problem with my
attitude ... you have a problem with the message... so I'm going to
stop trying to be nice about it publicly.. and I'm going to start
being completely open with my feelings on the matter.

-jef



From dr at cluenet.de  Fri Jul 15 16:10:37 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 18:10:37 +0200
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <20050714130732.GE16452@chrys.ms.mff.cuni.cz>
References: <55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
Message-ID: <20050715161037.GE10161@srv01.cluenet.de>

On Thu, Jul 14, 2005 at 03:07:38PM +0200, Miloslav Trmac wrote:
> On Thu, Jul 14, 2005 at 08:36:50AM -0400, Dimi Paun wrote:
> > Very smart. It seems that _anything_ is pointless to discuss here.
> Anything except development of Fedora.

Discussing and making decisions is INTEGRAL to the development process.
It's what actually should stand BEFORE hacking around randomly.

> Hijacking what is supposed to be a development list is not
> counterproductive?

It's not hijacking. It's using the list for what it's there. If you
think otherwise, please point to a more appropriate list. And actually
one where the Red Hat folks who actually make all the decisions really
take part in.

> > As I understand it, the entire point of having a _community_ distro like
> > Fedora is to channel all this customer feedback into a better product.
> Patches are the preferred form of feedback.

Nonsense.

I won't waste hours on writing a patch that gets just ignored. I don't
have this surplus time. My only chance to influence things is to bring
up my arguments. All else gets decided by Red Hat or "upstream" anyway
(and "upstream" can be overridden by Red Hat again if they like... if
RED HAT likes, not the community).

> I'd like everyone here to take a few minutes and read recent
> fedora-extras-list or fedora-maintainers-readonly archives.
> That's what development discussions look like, and not
> what one can see on this list.

-extras isn't Core, and we discuss here problems with Core. -readonly
is: <drumroll> READ ONLY </drumroll>.

> Sending off-topic mail here
> only means that development discussions will move to
> more closed places (fedora-maintainers), or stay at more closed
> places (internal Red Hat lists).

Well, that'd just mean less marketing material to back up the
"community distro" claim, that's all. We constantly hear that we're
being ignored anyway.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dr at cluenet.de  Fri Jul 15 16:15:41 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 18:15:41 +0200
Subject: No more right click terminal
In-Reply-To: <604aa79105071406403094ff4c@mail.gmail.com>
References: <55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
Message-ID: <20050715161541.GF10161@srv01.cluenet.de>

On Thu, Jul 14, 2005 at 09:40:57AM -0400, Jeff Spaleta wrote:
> My personal feelings on the matter are that people who refuse to move
> discussion to the most effective upstream forum, are delibrately
> attempting to cause problems or are only interested in browbeating
> other people with their opinions in an effort to score debating
> experience points.

You really have too much time. Guess what, there are users out there who
just want to USE Fedora. And contribute by giving their perspective of
what's wrong with Fedora, so Fedora (alias Red Hat) folks can make
educated decisions on what pieces to glue together, and what rough edges
to fix so their USER base gets what they look for.

I once was under the impression that all this here is done for users,
isn't it? So accept user feedback.

Wether it's "user" or "customer", and "paid for it" or not doesn't
matter. Either you are self-serving, or you do it for a purpose. And I
thought the purpose is to make USERS happy with it.

> Once an issue or complaint is brought it... the
> quicker it can be moved to the appropriate upstream  forum or group
> the less frustrating it is for everyone.

Yeah, then the Fedora maintainers responsible for the component should
do it, as an aggregator for the Fedora user base. They follow the
upstream communication anyway. I don't have time for a few thousand
mails more per day.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From avi at argo.co.il  Fri Jul 15 16:17:09 2005
From: avi at argo.co.il (Avi Kivity)
Date: Fri, 15 Jul 2005 19:17:09 +0300
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1121008844.23706.83.camel@baythorne.infradead.org>
References: <1120942256.2944.26.camel@localhost.localdomain>	<1120962038.17002.5.camel@localhost.localdomain>
	<1121008844.23706.83.camel@baythorne.infradead.org>
Message-ID: <42D7E185.1090305@argo.co.il>

David Woodhouse wrote:

>If you have a public IPv4 address, then with about three lines of 'yes
>please' in your network configuration you can also have IPv6. 
>
>See http://linux.yyz.us/ipv6-fc2-howto.html
>
>You only really need the 'Simple setup' part, which is trivial to do.
>It's the same for FC4 as it was for FC2 (and indeed for RHL6, IIRC).
>
>IPv6 isn't hard, folks.
>
>  
>
I've tried that on my adsl connection and got it to partially work - I 
don't have the 2002: address.

is there a forum somewhere which could help me debug this?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From andy at warmcat.com  Fri Jul 15 16:34:06 2005
From: andy at warmcat.com (Andy Green)
Date: Fri, 15 Jul 2005 17:34:06 +0100
Subject: No more right click terminal
In-Reply-To: <604aa79105071509037054f9f1@mail.gmail.com>
References: <1121248417.16074.19.camel@goose>
	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<20050715140354.GB10161@srv01.cluenet.de>	<604aa791050715080950042ef5@mail.gmail.com>	<42D7D640.6020607@warmcat.com>
	<604aa79105071509037054f9f1@mail.gmail.com>
Message-ID: <42D7E57E.3030706@warmcat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Spaleta wrote:
| On 7/15/05, Andy Green <andy at warmcat.com> wrote:
|
|>They understand that RHAT has some flexibility
|>in terms of overrides (patches) of upstream providers.
|
| And when they bring it up with regard to gnome desktop functionality,

My point was that Redhat is not a powerless bystander that is forced to
distribute whatever Gnome hands down from their ivory tower.  If it gets
beyond a certain point, RHAT will react themselves to the crap on the
stone tablets from upstream.

|>Although I don't use Gnome as a desktop, I use enough Gnome apps to be
|>constantly reminded of the ineffective choices

| All of this, are comments on gnome's process for introducing and
| laying out features. Without  making a judgement as to whether or not
| your concerns are valid, these would be more effectively expressed as
| part of upstream gnome discussions or in the case of the keyboard
| shortcuts, rfes into upstream bugzilla.

I do understand your agnosticism expressed here.  However, I assert the
choice to install *Fedora*, not Gnome.  Fedora has pushback powers both
in terms of implicit backchannels and explicit patching.  This is as
much the reality as saying that Gnome control Gonme.  Washing your hands
of it and saying it is out of your control is escapism.

|>> If you'd like to discuss more ideas for fedora marketting taglines,
|>> there is a mailinglist dedicated for fedora marketting.
|>
|>Well despite taking your point that upstream has more power over the
|>direction of upstream, some care needs to be taken not to blow off
|>genuine observations.  The power of RHAT to patch its desires into
|>reality is real, as we see in the kernel.
|
| No one has blown off the observations with regard to the specific

Sorry to disagree, but the "marketing" stuff was a cute way to blow the
guy off.  There are over blow-offs on the thread already.

| issue of terminal menu item. Clark chimed in very early on with
| upstream information concerning how the terminal menu item is being
| re-implemented as an addon. People took that information and are now
| starting the packaging of that addon for Extras.

"Those whom the Gods wish to destroy, they first send to Extras".
Extras is by definition no longer Fedora 'Core'.  Microsoft are very
familiar with the I'll-give-you-what-I-want-you-to-have-and-you-can
- -install-something-else-if-you-want-but-you're-too-lazy-haha-I'm-rich.

| But this thread degraded into general comments about how gnome is
| making upstream decisions, about how gnome has become a "social
| experiement" on users. Even YOU just now decided it was worthwhile to
| make a comment about how upstream gnome is changing defaults and how
| you think they should be doing it.  These sorts of comments don't need
| to be discussed here.. in fact they will get lost in the noise and
| never make it back to gnome.

I disagree with the thrust of this paragraph.  What is Fedora, some kind
of moral vacuum that just takes every upstream even if it is degenerate?
~ The pushback here is an appeal to *Fedora* that Gnome is going
backwards and arguably - because I am trying to be modest as Gnome
should be - needs a paternal hand on the shoulder and word in the ear.
And Fedora has that Gravitas to apply if the need is genuine.  Doesn't it.

| To quote you again:
| "It seems to me there is a genuine problem with the trend of Gnome
| development and the use of changing defaults to try to program their
| users."
|
| In no way shape or form is a comment about the "trend of gnome
| development" worthwhile to discuss in fedora-devel. Comments like
| these only serve to frustrate list participants, because comments
| about the general trends in gnome development made in this list are
| not going to lead to any changes into how gnome does things.   If you
| want to make a comment about "general trends" of ANY upstream
| project.. take it to the upstream project.

On this I take your point and it seems to me a reasonable stance.
HOWEVER Fedora is not some powerless insect that has to undergo whatever
convulsion grips the upstream components.

|>Well despite taking your point that upstream has more power over the
|>direction of upstream, some care needs to be taken not to blow off
|>genuine observations.  The power of RHAT to patch its desires into
|>reality is real, as we see in the kernel.

It's so good they quoted it twice.

| Its a huge logical fallacy to hold up what goes on with kernel
| development as an example of whats going on with desktop application
| development... inside redhat or even upstream.
| What the fedora kernel people think is appropriate in terms of
| patching the kernel.. is immaterial to what the desktop people think
| is appropriate in terms of patching gnome functionality. There are no
| parallels nor conclusions worth drawing in that comparison.

Logical fallacy / no parallels MY ASS.  The kernel is an rpm like the
others.  It's mostly C like the others.  It has patches from multiple
sources like the others.  Redhat take choices to override the Linus
version for tactical and forward-looking reasons.  Other RPMs likewise
have Redhat quirk patches.  Redhat exercise discretion to step in and
enforce their will when they decide to.  Don't be surprised therefore to
be appealed to on that basis.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC1+V+jKeDCxMJCTIRAmzcAJ4xzQjc3U3D4rx5fkKMTiRuBYXPzACeJSdD
k5hSu/zLUAHNsbGIHdCFm9E=
=5IwM
-----END PGP SIGNATURE-----



From dwmw2 at infradead.org  Fri Jul 15 16:36:22 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 15 Jul 2005 17:36:22 +0100
Subject: A quick look at the yum mirrorlists
In-Reply-To: <42D7E185.1090305@argo.co.il>
References: <1120942256.2944.26.camel@localhost.localdomain>
	<1120962038.17002.5.camel@localhost.localdomain>
	<1121008844.23706.83.camel@baythorne.infradead.org>
	<42D7E185.1090305@argo.co.il>
Message-ID: <1121445382.32417.16.camel@baythorne.infradead.org>

On Fri, 2005-07-15 at 19:17 +0300, Avi Kivity wrote:
> I've tried that on my adsl connection and got it to partially work - I
> don't have the 2002: address.

Hm. What is your public IPv4 address? When you bring the ADSL interface
up, does the tun6to4 interface not also get created? Can you show your
ifcfg-* file for the ADSL interface?

> is there a forum somewhere which could help me debug this?

#fedora on Freenode perhaps?

-- 
dwmw2




From dr at cluenet.de  Fri Jul 15 16:45:18 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 18:45:18 +0200
Subject: No more right click terminal
In-Reply-To: <604aa791050715080950042ef5@mail.gmail.com>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
Message-ID: <20050715164518.GG10161@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 11:09:26AM -0400, Jeff Spaleta wrote:
> On 7/15/05, Daniel Roesen <dr at cluenet.de> wrote:
> > The "we follow upstream!" mantra is also only followed when it's
> > fitting. 
> 
> Indeed, there are several people who maintain and help develop Core
> components. Those people all make judgement calls as to when its
> appropriate to break from upstream.  Its not worthwhile to point out
> that the policy of following upstream is not strictly enforced across
> the whole distribution.

It's only enforced if an easy one-liner is needed to tell people to go
away.

And the customization and many fixes that are done by Red Hat are
actually what we need a distro for. This is the ADDED VALUE.

> downstream.  I can't fathom why someone would choose to minimize
> rather than maximize their impact with regard to an issue they care
> enough about to spend time commenting on in a mailinglist.

Think a moment about the concept of aggregators.

> > The terminal launch option now disappearing completely out of immediate
> > reach is a major blow, once again. I really wonder where this is
> > heading. 
> 
> No need to wonder... If you get invovled or at least follow gnome
> development discussions upstream.. I'm sure you can get a clearer
> picture of project direction and momentum.

With how much effort, just to get something simple fixed? Aggregators
again.

When I as a developer (or actually in the distro case mostly patch kit
and package maintainer) see my users telling me that a change to the
software I take care of sucks, it's MY job to go to the upstream and try
to lobby for a reversal, AND/OR revert this change in my own distro
package.

And actually exactly that happens IFF the Red Hat employee making the
decisions agrees with the complaints. If not, the big "we follow
upstream, go away" stick is taken.

Of course, there are exceptions. But they are seldom.

> I accept the fact that metacity is not necessarily the best fit for
> all situations. I also accept the fact that default choices have to be
> made with a target group of users in mind. I also accept that its
> realistically when defaults have to be chosen the defaults will not be
> perfect for all users.

It's not about defaults. Changing defaults to fit whatever stereotype of
users GNOME developers have in mind isn't the worst thing. It's
annoying, sometimes highly annoying. But removing functionality sucks.

Enlightenment, integrated with GNOME (RHL 6.2, can you remember?) e.g.
had all the bells&whistles I ever needed. Over the years, the window
manager was replaced with ever worse replacements... less features, less
features, less, less. I'm surprised that we have a window manager at all
anymore. So, to get an effective system again, I have to do the
integration work for other window managers myself. Do I have the time?
No. Not the slightest. I have once tried with E under FC1... and gave
up. Never managed to get a nice integration like in RHL 6.2 again.

So now I'm standing here with metacity. Cannot even save window
positions, set positional attributes, nothing. To get extremely simple
things like "drag window to next virtual desktop by just taking it with
ALT key and dragging it around" I need to install additional software...

It's not about defaults. It's about removing/changing fundamental
functionality all the time. GNOME is more and more like Windows. I
feel more and more reminded on times where I had to use a Windows NT
desktop with TeraTerm/Putty all over the place.

And after writing this mail I go searching how to disable this annoying
"paste raises window" behaviour. "Desktop => Preferences => Windows"
has no option for that. I guess such an option was also removed for
"usability improvements".

> If you can't accept these statements as fact, you're head is in the
> wrong space and you are going to be continually frustrated by the
> gnome design process.

I'm not frustrated by the GNOME design process, but by the ignorance
of Fedora folks, at least some very vocal ones.

> I accept the choice of upstream gnome to have
> metacity as the default window manager even though it does not suit me
> personally in all situations.  I do not feel its worth arguing over
> defaults simply because my personal needs are not met with the default
> settings, as long as its "easy enough" to re-configure.

It's not "easy enough" to junk metacity and integrate another WM
yourself.

> In the case of the terminal menu item, its already been pointed out
> that people are working on packaging it up as an addon for Fedora
> Extras.

A lot of work, where Fedora maintainers could provide this with minimal
additional effort out-of-the-box. THAT's wasting resources.

> And I'm sure fvwm can find a home in Extras if a willing
> contributor wants to package it.

You obviously didn't get my point. I was taking twm and fvwm as examples
for extremely simple things which were cool 10+ years ago, but
technology should have advanced by now, but actually it stepped back
(metacity).

How nice it would be to have manual window positioning again when
there's no free screen real estate anymore. But that could confuse
GNOME's Windows user stereotype, so we prolly won't see it anymore...
and removing features is en vogue, not adding.

As as side note, Mozilla just needed MultiZilla to fit me. My Firefox
now has >20 Plugins to make it bearable. Now having to track 20 external
plugins for updates, and compatibility problems with newer Firefoxes...
all hail to removing features all around!

> In terms of re-configuration of
> gnome on a fedora system to move from defaults to "power-user"
> configs,

I _AM_NO_POWER_USER_. I just want to work efficiently with my computer
to do my REAL tasks. And Fedora makes it harder and harder (or the
GNOME folks for that matter, but the Fedora folks don't seem to care at
all, so they are in the same boat).

> Your complaints seem to me more about gnome defaults than anything
> fedora specific.

No, it's about Fedora's ignorance, and only in second step about GNOME
stupidities.

> Since gnome defaults impact more than just fedora, you should take
> your concerns to the gnome project directly in order to maximize the
> impact you will have across a number of distributions that provide a
> gnome desktop experience,

Guess what, I have long done with the idea to save the world. My day has
24 hours, where I'm usually 18-20 hours awake of. I simply don't have
the time to go "lobbying" in other high-volume mailing lists anymore
(just to hear there "then go to your distro vendor... customization is
what distros are there for" - AND THEY ARE RIGHT).

> -jef"i think someone is mistaking assuming i work for sombrero rojo"spaleta

No, but you have a habit of speaking in very authoritative form for
Fedora. Stop playing boss if you don't want to get the heat for it too.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From avi at argo.co.il  Fri Jul 15 16:47:04 2005
From: avi at argo.co.il (Avi Kivity)
Date: Fri, 15 Jul 2005 19:47:04 +0300
Subject: A quick look at the yum mirrorlists
In-Reply-To: <1121445382.32417.16.camel@baythorne.infradead.org>
References: <1120942256.2944.26.camel@localhost.localdomain>	
	<1120962038.17002.5.camel@localhost.localdomain>	
	<1121008844.23706.83.camel@baythorne.infradead.org>	
	<42D7E185.1090305@argo.co.il>
	<1121445382.32417.16.camel@baythorne.infradead.org>
Message-ID: <42D7E888.4010707@argo.co.il>

David Woodhouse wrote:

>On Fri, 2005-07-15 at 19:17 +0300, Avi Kivity wrote:
>  
>
>>I've tried that on my adsl connection and got it to partially work - I
>>don't have the 2002: address.
>>    
>>
>
>Hm. What is your public IPv4 address? When you bring the ADSL interface
>up, does the tun6to4 interface not also get created? Can you show your
>ifcfg-* file for the ADSL interface?
>
>  
>
sometimes a threat is sufficient. it started working on my latest 
network restart, even though I changed nothing.

ifconfig still doesn't show show the 2002: address on the tun6to4 
interface, but ip addr show does (it didn't before)

>>is there a forum somewhere which could help me debug this?
>>    
>>
>
>#fedora on Freenode perhaps?
>
>  
>
for the next problem... thanks.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From toshio at tiki-lounge.com  Fri Jul 15 16:53:35 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 15 Jul 2005 12:53:35 -0400
Subject: Taking up work (was: Re: No more right click terminal)
In-Reply-To: <42D695D5.5030204@redhat.com>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>
	<20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>  <42D695D5.5030204@redhat.com>
Message-ID: <1121446416.3128.9.camel@localhost>

On Thu, 2005-07-14 at 22:11 +0530, Rahul Sundaram wrote:
> Hi
> 
> >
> >1) Boilerplate similar to POSTISOFFTOPIC but specifically for addressing
> >issues to upstream.  A group of  volunteers to send the actual message
> >whenever a post is off topic.  Everyone else agrees to ignore off-topic
> >posts.
> >  
> >
> Ok. This one is easy. Just register yourself in fedoraproject.org/wiki 
> and let me know your username offlist. I will add you to the edit group. 
> You can go ahead and create templates then.

Not necessary -- I have all the rights to be able to do this.  However,
I won't have internet access starting tomorrow (and my time right now is
extremely limited as we have to finish our
packing/mailing/garbage/walk-thru/etc for moving today.)

I can work on these locally and put something up in three weeks or so.

I suggest it would be much better if someone else did this or came up
with a better idea.

> 
> >2) Start a project to package different default values for Extras.  We
> >have redhat-rpm-config changing rpm and fedora-release changing the
> >config of yum.  Maybe there should be a poweruser-gconf-tweaks.  (More
> >seriously, it should probably be more like config-nautilus-nonspatial,
> >config-rpmbuild-userdirs, config-metacity-focusfollows, etc)  this can
> >work for things that just require default config changes but will not
> >work for compilation/upstream code changes.
> >  
> >
> I would prefer people working on documenting these. A good desktop users 
> guide and "power" user FAQ's  for Fedora which details out the common 
> changes such as these would be useful. I dont think installing different 
> packages for trivial changes such as these is really a good idea. What 
> if you install this package and then change the configuration to a 
> conflicting value?
> 
Good idea!  Let's make that #4: Fedora Guide to Power-User Tweaks.  Are
you volunteering to create and edit it?  (I wasn't volunteering to head
a project to create defaults, so you can say no to this as well.)

> >3) Express interest in following upstream developments.  Encourage the
> >opening of bugzilla.redhat.com bugs with upstream bug #'s for these
> >issues.  There's no commitment to make changes, just a commitment to
> >actively monitor what upstream has to say about the issue and if
> >upstream commits to making a change, we'll do the same.
> >
> Oh. I just got flamed a couple of days back for telling people to report 
> bugs rather than rant on IRC channels and user lists. I am supposed to 
> be fixing bugzilla to be more end user friendly first. Dont ask me how. 
> I have no idea

I think you should take a page from espdiff (in the patchutils package)
and make a web form with a single button "Read my mind and figure out
what bug I'm reporting.  Then examine the programs on my computer and
perform a binary patch to fix the bug."  For extra credit, you could add
a single checkbox "Go back in time and fix this bug before I experienced
it" for use in Expert mode.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/da930310/attachment.sig>

From sundaram at redhat.com  Fri Jul 15 16:57:42 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 15 Jul 2005 22:27:42 +0530
Subject: Taking up work
In-Reply-To: <1121446416.3128.9.camel@localhost>
References: <1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com><1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com><1121344610.11210.99.camel@dimi>	<20050714125454.GC3984@redhat.com>	<033401c58885$94407f90$b6491b31@td612671>	<1121358709.4718.34.camel@localhost>
	<42D695D5.5030204@redhat.com> <1121446416.3128.9.camel@localhost>
Message-ID: <42D7EB06.60406@redhat.com>

Hi

>Good idea!  Let's make that #4: Fedora Guide to Power-User Tweaks.  Are
>you volunteering to create and edit it?  (I wasn't volunteering to head
>a project to create defaults, so you can say no to this as well.)
>  
>
I am willing to edit it but authoring is better done by people who love 
fiddling with these things. I rarely use such tools myself. If anyone 
else is interested see

http://fedoraproject.org/wiki/DocsProject/NewWriters

regards
Rahul



From dalive at flashmail.com  Fri Jul 15 17:08:41 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Fri, 15 Jul 2005 13:08:41 -0400
Subject: system-config-sshd ?
Message-ID: <42D7ED99.8050506@flashmail.com>

Hello,

I have been a Fedora user since FC1, and now I'd like to contribute to
the project. I know some Python, but no GUI (as yet). My more tested
programming skills lie is pascal and delphi. I am interested in building
a cnfiguration tool for sshd to help me learn the python language
better, and also to contribute to the fedora project. But I need some help:

Knowledge - HOWTOs, tutorial, whitepapers, etc that I need to read to
properly write a system-config applicat ion
Rules - Standards,  and guidelines that I shoudl follow
Technologies - gui toolkits, modules, etc that I should stick to in
learning and building a system-config tool.

Thanks for your assistance and time.

PS: the fedora-config-list is dead, so I'm reposting here



From mitr at volny.cz  Fri Jul 15 17:09:57 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Fri, 15 Jul 2005 19:09:57 +0200
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <20050715161037.GE10161@srv01.cluenet.de>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
	<20050715161037.GE10161@srv01.cluenet.de>
Message-ID: <20050715170950.GF19895@chrys.ms.mff.cuni.cz>

On Fri, Jul 15, 2005 at 06:10:37PM +0200, Daniel Roesen wrote:
> On Thu, Jul 14, 2005 at 03:07:38PM +0200, Miloslav Trmac wrote:
> > On Thu, Jul 14, 2005 at 08:36:50AM -0400, Dimi Paun wrote:
> > > Very smart. It seems that _anything_ is pointless to discuss here.
> > Anything except development of Fedora.
> Discussing and making decisions is INTEGRAL to the development process.
Not when there are 20 times more people attempting to make decisions than
people writing code.  And the decision all the people want overturned
is not a Fedora decision.

> It's what actually should stand BEFORE hacking around randomly.
That's what happened with GNOME 2.0.  If you don't like what they
decided to design, that's something different from thinking they
are designing it wrong.

> > Hijacking what is supposed to be a development list is not
> > counterproductive?
> It's not hijacking. It's using the list for what it's there.
http://www.redhat.com/mailman/listinfo/fedora-devel-list :
"Development discussions related to Fedora Core".
Where does that say "user's feedback"?

> If you
> think otherwise, please point to a more appropriate list.
I don't think there was _supposed_ to be a list for that.  There
is bugzilla (and no, spamming bugzilla with 100 duplicates to
"make a difference" is not appropriate.).

> And actually
> one where the Red Hat folks who actually make all the decisions really
> take part in.
I'm employed part-time and I'm reading fedora-{test,devel}-list in my
free time.  If I were reading this list on company time, I wouldn't actually
_get anything done, at all_.  Don't hold your breath waiting for such a list.
(*)

> > > As I understand it, the entire point of having a _community_ distro like
> > > Fedora is to channel all this customer feedback into a better product.
> > Patches are the preferred form of feedback.
> Nonsense.
> 
> I won't waste hours on writing a patch that gets just ignored.
There's nothing wrong about asking a package maintainer whether
a patch adding $feature has a chance to be accepted.

> All else gets decided by Red Hat or "upstream" anyway
> (and "upstream" can be overridden by Red Hat again if they like... if
> RED HAT likes, not the community).
Maybe it's time to clarify who "the community" is.

Very roughly, I interpret "the community" as "fedora-maintainers + people
who should be there" (e.g. I don't know whether the documentation or
translation team members are on the list).  The community of people who
_do_ things in Fedora.

> > I'd like everyone here to take a few minutes and read recent
> > fedora-extras-list or fedora-maintainers-readonly archives.
> > That's what development discussions look like, and not
> > what one can see on this list.
> 
> -extras isn't Core, and we discuss here problems with Core.
-extras has almost the same number of (source) packages and (very roughly)
the same number of developers as Core.  So what makes it OK to
post off-topic messages to fedora-devel-list?

> -readonly is: <drumroll> READ ONLY </drumroll>.
See (*).  If it were not read only, many "folks who actually make all
the decisions" would unsubscribe to be able to get work done.

There _was_ no fedora-maintainers when the first lists were created.

<em>fedora-maintainers is what fedora-devel-list was supposed to be.</em>
	Mirek



From toshio at tiki-lounge.com  Fri Jul 15 17:14:28 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 15 Jul 2005 13:14:28 -0400
Subject: No more right click terminal
In-Reply-To: <604aa79105071410036bc73ee@mail.gmail.com>
References: <1121248417.16074.19.camel@goose> <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
	<604aa79105071410036bc73ee@mail.gmail.com>
Message-ID: <1121447668.3128.23.camel@localhost>

On Thu, 2005-07-14 at 13:03 -0400, Jeff Spaleta wrote: 
> On 7/14/05, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> > 1) Boilerplate similar to POSTISOFFTOPIC but specifically for addressing
> > issues to upstream.  A group of  volunteers to send the actual message
> > whenever a post is off topic.  Everyone else agrees to ignore off-topic
> > posts.
> 
> Are you prepared to enforce that "agreement" by banning people who
> continue to responde to threads that are off-topic?  I'm prepared to
> "agree" to not post on a thread that has received a postisofftopic
> designation, just as long as people who don't abide by that agreement
> are shown the door.
> 
I'm prepared to accept that.  Don't think I'm prepared to support it
though.  These are ideas to encourage people about the community aspect
of Fedora.  Is banning people something that supports or discourages
community?  I think the first impression will be similar to the
-maintainers first impression.  Could even be worse unless we set up a
parallel fedora-devel-readonly list.  And what about redhat personnel?
One of the original Fedora openness requirements was that discussion was
to take place on the fedora-devel list.  Can they be banned?

I think banning people is somewhat of a different topic.

> 
> > 2) Start a project to package different default values for Extras.  We
> > have redhat-rpm-config changing rpm and fedora-release changing the
> > config of yum.  Maybe there should be a poweruser-gconf-tweaks.  (More
> > seriously, it should probably be more like config-nautilus-nonspatial,
> > config-rpmbuild-userdirs, config-metacity-focusfollows, etc)  this can
> > work for things that just require default config changes but will not
> > work for compilation/upstream code changes.
> 
> I really don't think you a whole slew of individual config tools for
> individual gconf key settings.

Yeah.  

Barring other options, I think it would be possible to do in a
non-horrendous fashion.  It would take a good deal of organization, to
achieve that, though, as the underlying structures don't enforce any of
the rules necessary to keep things sane.  I'd rather see other options
emerge.

> Can't you do this sort of thing for gnome desktops by providing
> pre-packaged sabayon profiles moving forward? Since sabayon seems to
> be exactly the tool aimed at administrors to created pre-cooked user
> profiles and apply those profiles to a user account as needed.

Sabayon certainly looks like it could be a more directed approach.  The
question I have, though, is whether Sabayon will let me ship a config to
Jesse, or Matthias to me.  In other words, not just from
system-administrator to user, but user to user.

The area I'm thinking needs to be filled is preference-themes.
Developers need a developer-oriented desktop.  Mom needs a
point-and-click oriented desktop.  Graphics designers need a
let-me-learn-as-I-work desktop.  Can Sabayon be used to create a
pre-cooked file that the end-user can download and install to utilize
the preferences they think are right?

Right now, I'm just brainstorming.  I identified a problem.  These are
some possible solutions.  Do you agree that the problem exists?  Do you
have an alternate off-the-wall solution?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/7826867b/attachment.sig>

From mitr at volny.cz  Fri Jul 15 17:20:24 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Fri, 15 Jul 2005 19:20:24 +0200
Subject: No more right click terminal
In-Reply-To: <42D7E57E.3030706@warmcat.com>
References: <1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
	<42D7D640.6020607@warmcat.com>
	<604aa79105071509037054f9f1@mail.gmail.com>
	<42D7E57E.3030706@warmcat.com>
Message-ID: <20050715172024.GG19895@chrys.ms.mff.cuni.cz>

On Fri, Jul 15, 2005 at 05:34:06PM +0100, Andy Green wrote:
> My point was that Redhat is not a powerless bystander that is forced to
> distribute whatever Gnome hands down from their ivory tower.  If it gets
> beyond a certain point, RHAT will react themselves to the crap on the
> stone tablets from upstream.
Yes, and the package maintainers _have_ taken a side on this issue.

> Logical fallacy / no parallels MY ASS.  The kernel is an rpm like the
> others.
No, it is not.  Most packages have a single maintainer; there are
two maintainers for OO.o, four (?) maintainers for X.Org X11; only
the kernel has a dedicated (and much larger) "kernel team".
	Mirek



From jspaleta at gmail.com  Fri Jul 15 17:26:50 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 13:26:50 -0400
Subject: No more right click terminal
In-Reply-To: <20050715164518.GG10161@srv01.cluenet.de>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
	<20050715164518.GG10161@srv01.cluenet.de>
Message-ID: <604aa79105071510265552bb4d@mail.gmail.com>

On 7/15/05, Daniel Roesen <dr at cluenet.de> wrote:
> So now I'm standing here with metacity. Cannot even save window
> positions, set positional attributes, nothing. To get extremely simple
> things like "drag window to next virtual desktop by just taking it with
> ALT key and dragging it around" I need to install additional software...

Why do you insist on expanding this discussion to include more and
more upstream decision making? This isnt constructive.

> 
> It's not about defaults. It's about removing/changing fundamental
> functionality all the time. GNOME is more and more like Windows. I
> feel more and more reminded on times where I had to use a Windows NT
> desktop with TeraTerm/Putty all over the place.

Again.. these concerns about general trends in gnome development
should be expressed to the upstream project lists to be most
effective.  I am telling you as a matter of fact, that discussions of
this nature have their best chance of resulting in action if they are
done upstream of any one distributor, especially a distributor who has
make it an objective to work as closely as possible with upstream.  In
fact lengthy discussion of this nature about upstream project process
is only going to serve to drive away fedora developers from
participating in this list. Let me make it clear... nothing demands
any fedora developer
to participate or even read this list. If general ever widening
discussions about the direction of upstream projects continue to
flurish on this list, more fedora developers are going to be using
other resources to communicate about fedora specific issues to avoid
the banter about problems upstream of fedora.  Noone has the ability
to keep up with all the lists, and this list becomes less relevant for
fedora developers when people choose not to show restraint by keeping
discussion from spiralling into a general one-sided argument about the
woes of upstream projects.

If I my goal was to submarine your concerns, I would encourage you to
continue to talk in a forum where I know your comments have little
chance of impacting upstream decisions.  In fact...now that i think
about it.. I think you are wrong on several counts and I think gnome
is best served by making sure your opinions never influence the
direction of the project. Please continue to talk about this on
fedora-devel.. do NOT take your concerns upstream.  Thank you for
helping my realize that my efforts to drive discussion to the
appropriate location only serves to work against my own personal
desires in what gnome is doing.  From now on, I will make sure I only
attempt to drive discussion to the appropriate place for discussion
that I judge to be worthwhile, instead of making in effort at all to
encourage opinions that differ with my own to be expressed where they
will be heard by the right people so they can be considered in an
informed way.

-jef"this post is off topic.. but please continue to discuss this
matter here as to avoid bothering upstream with your bad ideas"spaleta



From mitr at volny.cz  Fri Jul 15 17:28:53 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Fri, 15 Jul 2005 19:28:53 +0200
Subject: No more right click terminal
In-Reply-To: <20050715164518.GG10161@srv01.cluenet.de>
References: <1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
	<20050715164518.GG10161@srv01.cluenet.de>
Message-ID: <20050715172853.GH19895@chrys.ms.mff.cuni.cz>

On Fri, Jul 15, 2005 at 06:45:18PM +0200, Daniel Roesen wrote:
> > downstream.  I can't fathom why someone would choose to minimize
> > rather than maximize their impact with regard to an issue they care
> > enough about to spend time commenting on in a mailinglist.
> 
> Think a moment about the concept of aggregators.
The sole fact that you want package maintainers to be aggregating your
wishes does not make them aggregators automatically.  The package
maintainers have already refused to be your aggregators on this
issue several times.

> I _AM_NO_POWER_USER_.
Yes, you are.
	Mirek



From toshio at tiki-lounge.com  Fri Jul 15 17:35:16 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 15 Jul 2005 13:35:16 -0400
Subject: No more right click terminal
In-Reply-To: <1121447668.3128.23.camel@localhost>
References: <1121248417.16074.19.camel@goose> <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
	<604aa79105071410036bc73ee@mail.gmail.com>
	<1121447668.3128.23.camel@localhost>
Message-ID: <1121448916.3128.30.camel@localhost>

On Fri, 2005-07-15 at 13:14 -0400, Toshio Kuratomi wrote:
> On Thu, 2005-07-14 at 13:03 -0400, Jeff Spaleta wrote: 

> > Can't you do this sort of thing for gnome desktops by providing
> > pre-packaged sabayon profiles moving forward? Since sabayon seems to
> > be exactly the tool aimed at administrors to created pre-cooked user
> > profiles and apply those profiles to a user account as needed.
> 
> Sabayon certainly looks like it could be a more directed approach.  The
> question I have, though, is whether Sabayon will let me ship a config to
> Jesse, or Matthias to me.  In other words, not just from
> system-administrator to user, but user to user.
> 
> The area I'm thinking needs to be filled is preference-themes.
> Developers need a developer-oriented desktop.  Mom needs a
> point-and-click oriented desktop.  Graphics designers need a
> let-me-learn-as-I-work desktop.  Can Sabayon be used to create a
> pre-cooked file that the end-user can download and install to utilize
> the preferences they think are right?

Let me further clarify by saying that distribution of preferences does
not need to be a Fedora-specific project.  But it would be a great
project to point people who believe GNOME to be unresponsive to.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/1b62d3d1/attachment.sig>

From jkeating at j2solutions.net  Fri Jul 15 17:57:29 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 10:57:29 -0700
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <20050715170950.GF19895@chrys.ms.mff.cuni.cz>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
	<20050715161037.GE10161@srv01.cluenet.de>
	<20050715170950.GF19895@chrys.ms.mff.cuni.cz>
Message-ID: <1121450250.8029.5.camel@prometheus.gamehouse.com>

On Fri, 2005-07-15 at 19:09 +0200, Miloslav Trmac wrote:
> 
> Very roughly, I interpret "the community" as "fedora-maintainers + people
> who should be there" (e.g. I don't know whether the documentation or
> translation team members are on the list).  The community of people who
> _do_ things in Fedora.

So if the community is maintainers and other such users, but the target
audience is somebody far less advanced than this, how are we supposed to
get feedback from our target audience?  Would we not be better served by
coding and developing for the only groups we care to get feedback from?

-- 
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



From jspaleta at gmail.com  Fri Jul 15 17:54:35 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 13:54:35 -0400
Subject: No more right click terminal
In-Reply-To: <1121447668.3128.23.camel@localhost>
References: <1121248417.16074.19.camel@goose>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
	<604aa79105071410036bc73ee@mail.gmail.com>
	<1121447668.3128.23.camel@localhost>
Message-ID: <604aa79105071510543232b412@mail.gmail.com>

On 7/15/05, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> I'm prepared to accept that.  Don't think I'm prepared to support it
> though.  These are ideas to encourage people about the community aspect
> of Fedora.  Is banning people something that supports or discourages
> community?  

You said everyone needs to agree on respecting a boilerplate offtopic
post.  If people are expected to respect that boilerplate and stop
posting.. then i think its perfectly reasonable to espect that people
who dont respect that boilerplate response to be warned and if they
are habitual abusers asked to leave because they have disrespected
established agreed apun rules of conduct for the list.  If the
boilerplate offtopic response can't be relied on to move the
discussion... I don't see the point really in creating or using that
boilerplate response.


> I think the first impression will be similar to the
> -maintainers first impression.  Could even be worse unless we set up a
> parallel fedora-devel-readonly list.  And what about redhat personnel?

moderation for fedora-devel has been suggested repeatedly to me and in
the past i have always fought against it. At this point I frankly
don't care to fight the suggestion any longer. Now that maintainers is
open as a tool for contributors, the -devel list has lost much of its
relevancy as a useful tool among contributors... I'm no longer going
to make the effort to encourage better signal to noise here.  From now
on, I'm just looking for ideas I agree with and will help make sure
those ideas make it to the right people.
 
> One of the original Fedora openness requirements was that discussion was
> to take place on the fedora-devel list.  Can they be banned?

Acceptable use policies can still apply to open lists. If everyone
participating is suppose to agree to respect the boilerplate response
you proposed that I think its perfectly reasonable to enforce that
agreement on pain of death.

> I think banning people is somewhat of a different topic.

Shrug, feel free to create the boilerplate and use it as you see fit.
I fully expect certain people to ignore the boilerplate and to
continue to discuss the material you deemed as off topic.

> Sabayon certainly looks like it could be a more directed approach.  The
> question I have, though, is whether Sabayon will let me ship a config to
> Jesse, or Matthias to me.  In other words, not just from
> system-administrator to user, but user to user.

I have no idea.

> The area I'm thinking needs to be filled is preference-themes.
> Developers need a developer-oriented desktop.  Mom needs a
> point-and-click oriented desktop.  Graphics designers need a
> let-me-learn-as-I-work desktop.  Can Sabayon be used to create a
> pre-cooked file that the end-user can download and install to utilize
> the preferences they think are right?

I think thats sort of the idea.... to have different user profiles for
an admin to use. The admin applies one of the N user profiles via
sabayon to one of M users. N!=M.

> Right now, I'm just brainstorming.  I identified a problem.  These are
> some possible solutions.  Do you agree that the problem exists?  Do you
> have an alternate off-the-wall solution?

Right now, my best understanding is that sabayon is meant to fill this
niche on simplifying how to move a user from defaults to one of a
number of different profile configurations. I don't know if you can
easily pull in sabayon profile definitions from one box to another..
or what it would take to pre-package a profile in an rpm in extras. 
Something to talk to the sabayon developers about.  It certaintly
seems like there should be a way to easily trade sabayon profiles
across machines.

-jef"sabayon profiles.. collect them all!"spaleta



From jspaleta at gmail.com  Fri Jul 15 18:05:38 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 14:05:38 -0400
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <1121450250.8029.5.camel@prometheus.gamehouse.com>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
	<20050715161037.GE10161@srv01.cluenet.de>
	<20050715170950.GF19895@chrys.ms.mff.cuni.cz>
	<1121450250.8029.5.camel@prometheus.gamehouse.com>
Message-ID: <604aa7910507151105291922b1@mail.gmail.com>

On 7/15/05, Jesse Keating <jkeating at j2solutions.net> wrote:
> So if the community is maintainers and other such users, but the target
> audience is somebody far less advanced than this, how are we supposed to
> get feedback from our target audience?  

You create mechanisms by which you actively seek out feedback from the
target userbase via a repeatable methodology.   I'm very sure the
gnome usability group has some very concrete ideas on how to reach and
interact with a target audience that differs from the contributing
audience.

> Would we not be better served by
> coding and developing for the only groups we care to get feedback from?

Once you have mechanisms by which to actively seek out feedback that
can be applied to any target group.. you can get feedback from any
number of groups and make weighted decisions based on the feedback you
have collected.

-jef



From jkeating at j2solutions.net  Fri Jul 15 18:17:16 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 11:17:16 -0700
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <604aa7910507151105291922b1@mail.gmail.com>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
	<20050715161037.GE10161@srv01.cluenet.de>
	<20050715170950.GF19895@chrys.ms.mff.cuni.cz>
	<1121450250.8029.5.camel@prometheus.gamehouse.com>
	<604aa7910507151105291922b1@mail.gmail.com>
Message-ID: <1121451436.8029.7.camel@prometheus.gamehouse.com>

On Fri, 2005-07-15 at 14:05 -0400, Jeff Spaleta wrote:
> You create mechanisms by which you actively seek out feedback from the
> target userbase via a repeatable methodology.   I'm very sure the
> gnome usability group has some very concrete ideas on how to reach and
> interact with a target audience that differs from the contributing
> audience.

I guess my question is more "Is Gnome's target audience the same as
Fedora's target audience?"  This is where I seem to see a disconnect.

-- 
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



From sundaram at redhat.com  Fri Jul 15 18:10:52 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 15 Jul 2005 23:40:52 +0530
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <1121451436.8029.7.camel@prometheus.gamehouse.com>
References: <1121272795.13335.18.camel@localhost.localdomain>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>	<20050715161037.GE10161@srv01.cluenet.de>	<20050715170950.GF19895@chrys.ms.mff.cuni.cz>	<1121450250.8029.5.camel@prometheus.gamehouse.com>	<604aa7910507151105291922b1@mail.gmail.com>
	<1121451436.8029.7.camel@prometheus.gamehouse.com>
Message-ID: <42D7FC2C.5050806@redhat.com>

Jesse Keating wrote:

>On Fri, 2005-07-15 at 14:05 -0400, Jeff Spaleta wrote:
>  
>
>>You create mechanisms by which you actively seek out feedback from the
>>target userbase via a repeatable methodology.   I'm very sure the
>>gnome usability group has some very concrete ideas on how to reach and
>>interact with a target audience that differs from the contributing
>>audience.
>>    
>>
>
>I guess my question is more "Is Gnome's target audience the same as
>Fedora's target audience?"  This is where I seem to see a disconnect.
>  
>
 From the overlap between the GNOME development team and the Fedora 
Desktop team I would consider the desktop goals to be fairly aligned.  
The distribution itself has a much larger target audience. Thats my take 
on it

regards
Rahul



From jkeating at j2solutions.net  Fri Jul 15 18:28:49 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 11:28:49 -0700
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <42D7FC2C.5050806@redhat.com>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
	<20050715161037.GE10161@srv01.cluenet.de>
	<20050715170950.GF19895@chrys.ms.mff.cuni.cz>
	<1121450250.8029.5.camel@prometheus.gamehouse.com>
	<604aa7910507151105291922b1@mail.gmail.com>
	<1121451436.8029.7.camel@prometheus.gamehouse.com>
	<42D7FC2C.5050806@redhat.com>
Message-ID: <1121452129.8029.13.camel@prometheus.gamehouse.com>

On Fri, 2005-07-15 at 23:40 +0530, Rahul Sundaram wrote:
>  From the overlap between the GNOME development team and the Fedora 
> Desktop team I would consider the desktop goals to be fairly aligned.  
> The distribution itself has a much larger target audience. Thats my take 
> on it

So it seems a little odd to me to be designing a desktop geared for
newbies and the non-technical, on a platform that is designed for
hobbiests and early adopters of new technology and people who wish to
contribute and hope to direct the path of the distribution in the
process.  To me, these two do not mesh well.

-- 
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



From jspaleta at gmail.com  Fri Jul 15 18:21:21 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 14:21:21 -0400
Subject: List purpose (was Re: No more right click terminal)
In-Reply-To: <1121451436.8029.7.camel@prometheus.gamehouse.com>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050714130732.GE16452@chrys.ms.mff.cuni.cz>
	<20050715161037.GE10161@srv01.cluenet.de>
	<20050715170950.GF19895@chrys.ms.mff.cuni.cz>
	<1121450250.8029.5.camel@prometheus.gamehouse.com>
	<604aa7910507151105291922b1@mail.gmail.com>
	<1121451436.8029.7.camel@prometheus.gamehouse.com>
Message-ID: <604aa7910507151121adaf5f4@mail.gmail.com>

On 7/15/05, Jesse Keating <jkeating at j2solutions.net> wrote:
> I guess my question is more "Is Gnome's target audience the same as
> Fedora's target audience?"  This is where I seem to see a disconnect.

At the distribution level.. i don't think there has been any effort to
make a clear statement as for whom long term design is aimed at.
Clearly gnome as the default destop and the intent to follow upstream
decisions more faithfully than I brush my teeth, makes gnome's target
audience decisions weight heavily on the fedora desktop target
audience. Outside of the desktop i dont think there is distinction
made as to which audiences fedora is trying to design for in the long
term. Outside of the desktop... what does design for a novice or power
user really mean when you are outside of the desktop anyways?  Can you
design a kernel for novices?

-jef



From andy at warmcat.com  Fri Jul 15 18:59:43 2005
From: andy at warmcat.com (Andy Green)
Date: Fri, 15 Jul 2005 19:59:43 +0100
Subject: No more right click terminal
In-Reply-To: <20050715172024.GG19895@chrys.ms.mff.cuni.cz>
References: <1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<20050715140354.GB10161@srv01.cluenet.de>	<604aa791050715080950042ef5@mail.gmail.com>	<42D7D640.6020607@warmcat.com>	<604aa79105071509037054f9f1@mail.gmail.com>	<42D7E57E.3030706@warmcat.com>
	<20050715172024.GG19895@chrys.ms.mff.cuni.cz>
Message-ID: <42D8079F.4030204@warmcat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miloslav Trmac wrote:

|>Logical fallacy / no parallels MY ASS.  The kernel is an rpm like the
|>others.

| No, it is not.  Most packages have a single maintainer; there are
| two maintainers for OO.o, four (?) maintainers for X.Org X11; only
| the kernel has a dedicated (and much larger) "kernel team".

It's larger, it has more patches, more people have to look after it.
It's an RPM, same format as everything else, contains normal files,
encapsulates an external .tar.gz compilable project, and contains
deviations from upstream mandated by Redhat like other packages do.

Show me the "logical fallacy" drawing a line between that RPM and the
rest of 'em just because it has more people on it.  Sure I understand if
RHAT doesn't want to get their fingers into any more ongoing Chinese
Finger Traps of deviant maintainence.

RHAT deviations from upstream are basically a private RHAT political
issue.  They pay for it, why not.  Naturally this leads to winces when
the "C-word" is trotted out next to Fedora.

Anyway I use your work daily, thanks to everyone for all their work.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC2AefjKeDCxMJCTIRAixZAJ4+f1OQd+Q9Q18MfiQPdUj7Lrzh4ACfbY5+
Ef8pEWs2C5QI6yiiu1GLJko=
=uwif
-----END PGP SIGNATURE-----



From ivazquez at ivazquez.net  Fri Jul 15 19:47:22 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 15 Jul 2005 15:47:22 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <20050715155226.GA32637@nostromo.devel.redhat.com>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121387466.6290.20.camel@ignacio.lan>
	<1121412635.6290.28.camel@ignacio.lan>
	<20050715155226.GA32637@nostromo.devel.redhat.com>
Message-ID: <1121456842.10063.1.camel@ignacio.lan>

On Fri, 2005-07-15 at 11:52 -0400, Bill Nottingham wrote:
> Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> > Never mind, I found it.
> > 
> > *sigh*
> > 
> > I also discovered, upon reading the udev docs more closely, that it will
> > *not* work for devices that have a user-mode driver, which fries sane as
> > well.
> 
> Why wouldn't it? It's getting the same hotplug events.

Apparently udev can't see them.

"The first thing you need to do is find a directory somewhere in /sys
that corresponds to your hardware, and includes a file named "dev", as
udevinfo can only work on directories of this type. These directories
are all found under either /sys/block or /sys/class - there is no point
looking anywhere else!"

User-mode drivers don't give the device a block or class designator, and
so udev won't handle them.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/3432e281/attachment.sig>

From carljohan at design.chalmers.se  Fri Jul 15 19:48:39 2005
From: carljohan at design.chalmers.se (Carl-Johan Kjellander)
Date: Fri, 15 Jul 2005 21:48:39 +0200
Subject: stateless-linux troubles when updating kernel.
Message-ID: <42D81317.6060307@design.chalmers.se>

I ran into som troubles with stateless-linux today.

I have a protosystem, and I chroot:ed into it, mounted /proc and
did a 'yum -y update'. That ran fine and installed a new kernel
among other things. But upon running stateless-snapshooter I ran
into some troubles:

# stateless-snapshooter -n -p minimal
     ##################################################################(100%)
Traceback (most recent call last):
   File "/usr/share/stateless/snapshooter.py", line 177, in transfer_finished
     self.prepare_destination()
   File "/usr/share/stateless/snapshooter.py", line 263, in prepare_destination
     self.copy_pxeboot_files ()
   File "/usr/share/stateless/snapshooter.py", line 251, in copy_pxeboot_files
     copy_from_snapshot ("diskless-initrd-%s.img" % latest_kernel, 'initrd.img')
   File "/usr/share/stateless/snapshooter.py", line 246, in copy_from_snapshot
     shutil.copy (src_path, dest_path)
   File "/usr/lib/python2.3/shutil.py", line 71, in copy
     copyfile(src, dst)
   File "/usr/lib/python2.3/shutil.py", line 37, in copyfile
     fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: '/srv/stateless/snapshots/minimal/minimal-2/boot/diskless-initrd-2.6.11-1.35_FC3.img'

Which script creates the diskless-initrd? And why doesn't it generate
a new one for the new kernel? I have an old one but I wanna use
the new one.

And does it generate one for the SMP kernel as well cause I wanna use that
kernel for my P4?

/cjk
-- 
begin 644 carljohan_at_kjellander_dot_com.gif
Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I
Y*=NX,2 at OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6H<SH-"E*TJ3%*/>QI6:7"A>Y?):D2^*U at NCV
R<MOQ=]V(B6>LZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L`



From seyman at wanadoo.fr  Fri Jul 15 19:59:45 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 15 Jul 2005 21:59:45 +0200
Subject: No more right click terminal
In-Reply-To: <20050715161541.GF10161@srv01.cluenet.de>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
Message-ID: <20050715195945.GA4432@orient.maison.moi>

On Fri, Jul 15, 2005 at 06:15:41PM +0200, Daniel Roesen wrote:
> 
> I once was under the impression that all this here is done for users,
> isn't it? So accept user feedback.

Let me get this straight.

Case A:

- User finds something he dislikes about Fedora's Gnome desktop.
- User complains to fedora-devel-list/fedora-list/bugzilla.redhat.com/...
- User is told to take his complaint upstream.
- User takes his complaint upstream.
- Developer takes complaint and cooks up patch/change/workabout/...
- Change is released in the following Gnome version.
- Change is included in every Gnome installation (including Fedora's).

Case B:

- User finds something he dislikes about Fedora's Gnome desktop.
- User complains to fedora-devel-list/fedora-list/bugzilla.redhat.com/...
- Fedora maintainer add patchs to package.
- Next Fedora version includes said patch.

with the following effects:

- Developer complains about changes and refuses to handle bug reports about
the fedora package (whether the bug reports are related to the patch or not).
- Maintainer has to maintain said patch for life.
- User is never introduced to new (possibly better) ways of using his desktop.
- Users of other distributions are still using the crappy (according to the
user) Gnome desktop).

Now, I don't see any possible way Case B could be argued more effective than
Case A. In fact, I think it's worse in every possible respect.

Emmanuel



From rms at 1407.org  Fri Jul 15 20:07:32 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 15 Jul 2005 21:07:32 +0100
Subject: No more right click terminal
In-Reply-To: <20050715195945.GA4432@orient.maison.moi>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
Message-ID: <1121458052.2914.1.camel@roque>

On Fri, 2005-07-15 at 21:59 +0200, Emmanuel Seyman wrote:
> Now, I don't see any possible way Case B could be argued more effective than
> Case A. In fact, I think it's worse in every possible respect.

Yes. But sometimes B is needed.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/28d5382b/attachment.sig>

From jkeating at j2solutions.net  Fri Jul 15 20:20:41 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 13:20:41 -0700
Subject: No more right click terminal
In-Reply-To: <20050715195945.GA4432@orient.maison.moi>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
Message-ID: <1121458841.8029.22.camel@prometheus.gamehouse.com>

On Fri, 2005-07-15 at 21:59 +0200, Emmanuel Seyman wrote:
> Now, I don't see any possible way Case B could be argued more
> effective than
> Case A. In fact, I think it's worse in every possible respect.
> 

Case C:
- User(s) find somethiing they dislike about Fedora's Gnoem desktop
- User complains to fedora-devel-list/fedora-list/bugzilla.redhat.com/...
- Fedora maintainer sees many many complaints about feature and takes
issue upstream or to application developer. (maintainer != developer in
some (most?) cases)
- Fedora maintainer or developer act as aggregate voice of userbase to
Gnome and pushes to get feature corrected upstream.
- As last resort Fedora maintainer creates patch or takes stance and
provides quantitave reasoning as to why they are sticking w/ feature
that lots dislike

End result?  Community and target users do see that maintainers care and
listen and try for the end user's best interest.

-- 
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



From dr at cluenet.de  Fri Jul 15 20:15:37 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 15 Jul 2005 22:15:37 +0200
Subject: No more right click terminal
In-Reply-To: <1121458841.8029.22.camel@prometheus.gamehouse.com>
References: <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
Message-ID: <20050715201537.GA14049@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 01:20:41PM -0700, Jesse Keating wrote:
> Case C:
> - User(s) find somethiing they dislike about Fedora's Gnoem desktop
> - User complains to fedora-devel-list/fedora-list/bugzilla.redhat.com/...
> - Fedora maintainer sees many many complaints about feature and takes
> issue upstream or to application developer. (maintainer != developer in
> some (most?) cases)
> - Fedora maintainer or developer act as aggregate voice of userbase to
> Gnome and pushes to get feature corrected upstream.
> - As last resort Fedora maintainer creates patch or takes stance and
> provides quantitave reasoning as to why they are sticking w/ feature
> that lots dislike
> 
> End result?  Community and target users do see that maintainers care and
> listen and try for the end user's best interest.

Exactly THIS is the model I'm talking about and that I would want to
see from any distro that cares about their user base.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From sjansen at gurulabs.com  Fri Jul 15 20:38:34 2005
From: sjansen at gurulabs.com (Stuart Jansen)
Date: Fri, 15 Jul 2005 14:38:34 -0600
Subject: No more right click terminal
In-Reply-To: <20050715201537.GA14049@srv01.cluenet.de>
References: <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
Message-ID: <1121459914.25236.26.camel@localhost.localdomain>

On Fri, 2005-07-15 at 22:15 +0200, Daniel Roesen wrote:
> Exactly THIS is the model I'm talking about and that I would want to
> see from any distro that cares about their user base.

Sure, and it'd be nice if on their way home the maintainers would drop
by my place to wash my car and clean my apartment.

I'd rather see the Fedora developers fight bugs than aggregate user
requests and write patches. If you were paying for their services, I
could see making demands of maintainers. As your not, I think it is
reasonable to expect you to deal with upstream yourself. Ultimately,
F/OSS is not a democracy, it is a meritocracy. Your influence is
directly proportional to the value of your contribution--and talk is
cheap.

-- 
Stuart Jansen <sjansen at gurulabs.com>
Guru Labs, L.C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/2574bb2e/attachment.sig>

From seyman at wanadoo.fr  Fri Jul 15 20:55:40 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 15 Jul 2005 22:55:40 +0200
Subject: No more right click terminal
In-Reply-To: <1121458841.8029.22.camel@prometheus.gamehouse.com>
References: <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
Message-ID: <20050715205540.GA5910@orient.maison.moi>

On Fri, Jul 15, 2005 at 01:20:41PM -0700, Jesse Keating wrote:
> 
> End result?  Community and target users do see that maintainers care and
> listen and try for the end user's best interest.

Try: Maintainer's head explodes from the amount of work this implies.

Your case implies that complaining to the maintainer is easier
than complaining upstream. Why would this be true ?

Emmanuel



From notting at redhat.com  Fri Jul 15 21:05:34 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 15 Jul 2005 17:05:34 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <1121456842.10063.1.camel@ignacio.lan>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121387466.6290.20.camel@ignacio.lan>
	<1121412635.6290.28.camel@ignacio.lan>
	<20050715155226.GA32637@nostromo.devel.redhat.com>
	<1121456842.10063.1.camel@ignacio.lan>
Message-ID: <20050715210534.GD2895@nostromo.devel.redhat.com>

Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> Apparently udev can't see them.
> 
> "The first thing you need to do is find a directory somewhere in /sys
> that corresponds to your hardware, and includes a file named "dev", as
> udevinfo can only work on directories of this type. These directories
> are all found under either /sys/block or /sys/class - there is no point
> looking anywhere else!"
> 
> User-mode drivers don't give the device a block or class designator, and
> so udev won't handle them.

Sure it will.

At the end of udev.rules:

ACTION=="add", SUBSYSTEM=="usb", MODALIAS=="*", \
        RUN+="/sbin/modprobe $modalias"

This gets run for all usb devices to *try* and load a driver. It's running
before the kernel could know whether or not a driver is kenrel or
userspace.

Perhaps the udev docs need some help.

Bill



From jkeating at j2solutions.net  Fri Jul 15 21:16:20 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 14:16:20 -0700
Subject: No more right click terminal
In-Reply-To: <20050715205540.GA5910@orient.maison.moi>
References: <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
Message-ID: <1121462180.8029.30.camel@prometheus.gamehouse.com>

On Fri, 2005-07-15 at 22:55 +0200, Emmanuel Seyman wrote:
> Try: Maintainer's head explodes from the amount of work this implies.
> 
> Your case implies that complaining to the maintainer is easier
> than complaining upstream. Why would this be true ?

By sending it upstream, all you're doing is sending the 'explosion'
somewhere else to be ignored.  I'm not saying every single complaint has
to be addressed, but when a large contingency of users have issues with
something, perhaps then it is time to step up and be the champion for
the userbase.

-- 
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



From walters at redhat.com  Fri Jul 15 21:16:07 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 17:16:07 -0400
Subject: No more right click terminal
In-Reply-To: <orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <1121462167.4036.32.camel@nexus.verbum.private>

On Thu, 2005-07-14 at 14:32 -0300, Alexandre Oliva wrote:
> On Jul 13, 2005, Colin Walters <walters at redhat.com> wrote:
> 
> > Think of it this way: what if GNOME's historical audience had been
> > musicians?  Then the right click menu might have had 
> > "Open Musical Score Composer".  Having that makes as much sense to the
> > general population as "Open Terminal" does.
> 
> FWIW, when I first introduced Cygwin to a musician friend of mine, he
> absolutely *loved* the ability to issue commands without having to
> point and click, and the ability to write scripts to automate common
> or repetitive tasks.

If your friend can write scripts, that means he or she has a level of
technical knowledge we can not expect of all users.

> Terminals should not be thought of as power-users only; they're useful
> for everybody.

Completely, totally disagree.  Every time a non-developer/non-sysadmin
has to use the terminal for something is a bug.

>   Perhaps our desktop approach should take a stance
> similar to AIX SMIT (sp?), a system administration front-end that
> would not only enable you to perform various tasks with a point&click
> interface, but *also* let you know the commands it was running to
> perform those tasks.  

Let me suggest something to you - what if we took an stance with GCC
where when it compiled C code, it popped up a curses application which
told you how you could be writing by hand the assembler it was
generating and how it was doing.  Here's how the register allocator
works, here's how it optimized away variable x, etc...

Now, I happen to be one of the people who is in the target audience for
GCC.  The entire reason I use GCC is because I don't *want* to know or
care about assembler.  Just like our desktop, for the vast majority of
people, GCC is a tool they use to get a job done, not something they
care to know the internals of.  The curses/GCC thing would be extremely
annoying at best for people just trying to get a job done, exactly like
your suggestion of desktop commands would be.

> I'm told Autocad is very much like this as well,
> and even architects without any prior programming expertise end up
> being able to automate tasks using the lisp-based programming
> interface, which is one of the features that makes it so powerful.

Autocad is a very specialized tool for a particular audience.  You can
probably assume that most of its users spend 8 hours a day for years in
front of it and that any time they can save helps a lot.

The same is not true in general.  It is not worth the time for most
users to learn how to program just so you can save a few seconds off
your OpenOffice usage or whatever.

Don't get me wrong: it *would* be nice if we had an equivalent to
AppleScript so somewhat technically inclined users could script apps for
relatively obscure use cases.  But that's no substitute for actually
fixing the desktop to just work for the major cases.

> This gave you the option to remain clueless 

I think this reveals a lot about how you think about our target users.
If you consider them "clueless" and think that they have some need to
know how computers work and how to program or else they're stupid, that
strikes me as rather negative and arrogant.

Personally, I think *we* are the clueless ones, who spend all of our
time in front of computers learning how they work.  The truly smart
people are the ones who became surfing instructors at some beach in
Hawaii and rarely see a computer.

People in general want to use the computer to do their work, send email
occasionally or something, and could care less how they work at all (and
definitely don't care to learn how to program).

You'd think this would be common sense...I feel pretty silly even
explaining it.

> Did it change?  I didn't notice any changes whatsoever in my panel.
> Sure enough, I would, should I wipe out all of my gnome settings and
> started from scratch, I guess.  (Un?)fortunately there's no easy way
> to track the defaults while keeping the settings you've overridden,
> AFAIK.  Open Terminal, OTOH, has changed regardless of my settings.

True; but the change is a benefit by default to most users, so we need
to have it enabled by default.  You can express your preference for
having terminal easy to access by installing nautilus-open-terminal or
adding a hotkey for it or whatever.




From cmadams at hiwaay.net  Fri Jul 15 21:17:52 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 15 Jul 2005 16:17:52 -0500
Subject: No more right click terminal
In-Reply-To: <1121462167.4036.32.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
Message-ID: <20050715211752.GE954722@hiwaay.net>

Once upon a time, Colin Walters <walters at redhat.com> said:
> Completely, totally disagree.  Every time a non-developer/non-sysadmin
> has to use the terminal for something is a bug.

Let me know when you invent a GUI SSH.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From walters at redhat.com  Fri Jul 15 21:19:16 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 17:19:16 -0400
Subject: No more right click terminal
In-Reply-To: <20050715211752.GE954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
Message-ID: <1121462356.4036.34.camel@nexus.verbum.private>

On Fri, 2005-07-15 at 16:17 -0500, Chris Adams wrote:
> Once upon a time, Colin Walters <walters at redhat.com> said:
> > Completely, totally disagree.  Every time a non-developer/non-sysadmin
> > has to use the terminal for something is a bug.
> 
> Let me know when you invent a GUI SSH.

What do you use ssh for?




From sundaram at redhat.com  Fri Jul 15 21:19:33 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 02:49:33 +0530
Subject: No more right click terminal
In-Reply-To: <20050715211752.GE954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<1121274056.10565.15.camel@nexus.verbum.private>	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
Message-ID: <42D82865.5030003@redhat.com>

Chris Adams wrote:

>Once upon a time, Colin Walters <walters at redhat.com> said:
>  
>
>>Completely, totally disagree.  Every time a non-developer/non-sysadmin
>>has to use the terminal for something is a bug.
>>    
>>
>
>Let me know when you invent a GUI SSH.
>  
>
Isnt SSH a administration tool?.

regards
Rahul



From dcbw at redhat.com  Fri Jul 15 21:20:55 2005
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 15 Jul 2005 17:20:55 -0400 (EDT)
Subject: No more right click terminal
In-Reply-To: <20050715211752.GE954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
Message-ID: <Pine.LNX.4.58.0507151719590.10424@devserv.devel.redhat.com>

On Fri, 15 Jul 2005, Chris Adams wrote:

> Once upon a time, Colin Walters <walters at redhat.com> said:
> > Completely, totally disagree.  Every time a non-developer/non-sysadmin
> > has to use the terminal for something is a bug.
> 
> Let me know when you invent a GUI SSH.

"non-developer/non-sysadmin" is the key here, these people most likely never 
have and never will care what SSH stand for or does.

Obviously its useful for sysadmin types right now, nobody disputes that.

Dan



From cmadams at hiwaay.net  Fri Jul 15 21:24:27 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 15 Jul 2005 16:24:27 -0500
Subject: No more right click terminal
In-Reply-To: <1121462356.4036.34.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<1121462356.4036.34.camel@nexus.verbum.private>
Message-ID: <20050715212427.GF954722@hiwaay.net>

Once upon a time, Colin Walters <walters at redhat.com> said:
> What do you use ssh for?

Accessing remote systems, for any number of reasons.

If you need to make a change to a big file on a remote web server, which
is better:

- ssh in and edit it with $EDITOR of choice
- transfer the file to your local system, edit it, and transfer it back

Also, since there's no way to set SELinux attributes via FTP or SFTP,
the only way to do so is via ssh.

And these are _not_ just system administrator things; we've got a few
thousand users that do things like this (not SELinux yet since we
haven't moved to that, but editing web pages).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From cmadams at hiwaay.net  Fri Jul 15 21:25:31 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 15 Jul 2005 16:25:31 -0500
Subject: No more right click terminal
In-Reply-To: <42D82865.5030003@redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net> <42D82865.5030003@redhat.com>
Message-ID: <20050715212531.GG954722@hiwaay.net>

Once upon a time, Rahul Sundaram <sundaram at redhat.com> said:
> Isnt SSH a administration tool?.

No, it is a remote access tool.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From cmadams at hiwaay.net  Fri Jul 15 21:27:43 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 15 Jul 2005 16:27:43 -0500
Subject: No more right click terminal
In-Reply-To: <Pine.LNX.4.58.0507151719590.10424@devserv.devel.redhat.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<Pine.LNX.4.58.0507151719590.10424@devserv.devel.redhat.com>
Message-ID: <20050715212743.GH954722@hiwaay.net>

Once upon a time, Dan Williams <dcbw at redhat.com> said:
> "non-developer/non-sysadmin" is the key here, these people most likely never 
> have and never will care what SSH stand for or does.
> 
> Obviously its useful for sysadmin types right now, nobody disputes that.

SSH is a tool for anyone that wants to access a remote system.

Haven't you people ever heard of web hosting?  We've got a several
thousand customers, and many of them prefer to edit their web sites on
the server, especially since transferring things back and forth is slow,
cumbersome, and sometimes troublesome to keep in sync.  There are tools
to make that easier (such as rsync, another terminal program), but it is
much easier for many people to simply have one copy of their web site on
the server.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From nmiell at comcast.net  Fri Jul 15 21:28:35 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Fri, 15 Jul 2005 14:28:35 -0700
Subject: No more right click terminal
In-Reply-To: <20050715211752.GE954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
Message-ID: <1121462915.2946.1.camel@localhost.localdomain>

On Fri, 2005-07-15 at 16:17 -0500, Chris Adams wrote:
> Once upon a time, Colin Walters <walters at redhat.com> said:
> > Completely, totally disagree.  Every time a non-developer/non-sysadmin
> > has to use the terminal for something is a bug.
> 
> Let me know when you invent a GUI SSH.

It's called rdesktop/vnc/Xnest + tsclient.

-- 
Nicholas Miell <nmiell at comcast.net>



From cmadams at hiwaay.net  Fri Jul 15 21:33:59 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 15 Jul 2005 16:33:59 -0500
Subject: No more right click terminal
In-Reply-To: <1121462915.2946.1.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<1121462915.2946.1.camel@localhost.localdomain>
Message-ID: <20050715213359.GI954722@hiwaay.net>

Once upon a time, Nicholas Miell <nmiell at comcast.net> said:
> On Fri, 2005-07-15 at 16:17 -0500, Chris Adams wrote:
> > Let me know when you invent a GUI SSH.
> 
> It's called rdesktop/vnc/Xnest + tsclient.

Not on my shared hosting servers it isn't.  I'm not going to run a bunch
of copies of X so users that can figure out VNC can avoid SSH.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From walters at redhat.com  Fri Jul 15 21:33:50 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 17:33:50 -0400
Subject: No more right click terminal
In-Reply-To: <20050715212427.GF954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<1121462356.4036.34.camel@nexus.verbum.private>
	<20050715212427.GF954722@hiwaay.net>
Message-ID: <1121463230.4036.42.camel@nexus.verbum.private>

On Fri, 2005-07-15 at 16:24 -0500, Chris Adams wrote:
> Once upon a time, Colin Walters <walters at redhat.com> said:
> > What do you use ssh for?
> 
> Accessing remote systems, for any number of reasons.
> 
> If you need to make a change to a big file on a remote web server, which
> is better:
> 
> - ssh in and edit it with $EDITOR of choice
> - transfer the file to your local system, edit it, and transfer it back

Or:

- Use a web page editing tool which knows how to invoke ssh or ftp or
  webdav or whatever?

Note that one could use GEdit (since it supports SFTP via gnome-vfs) as
a basic web page editing tool now if we just fixed the bug that it
refuses to save files over gnome-vfs (because the maintainers are on
crack).

> Also, since there's no way to set SELinux attributes via FTP or SFTP,
> the only way to do so is via ssh.

Yes, that's a bug.  One I personally want to see fixed (for SFTP at
least).

> And these are _not_ just system administrator things; we've got a few
> thousand users that do things like this 

Right, but what you are doing is working around the lack of a good web
page editing tool, which is a bug.





From ivazquez at ivazquez.net  Fri Jul 15 21:38:04 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 15 Jul 2005 17:38:04 -0400
Subject: libifp and the new udev (was: Re: PCMCIA & udev changes)
In-Reply-To: <20050715210534.GD2895@nostromo.devel.redhat.com>
References: <20050714041213.GA905@nostromo.devel.redhat.com>
	<1121315019.6290.2.camel@ignacio.lan>
	<20050714043316.GA1840@nostromo.devel.redhat.com>
	<1121328535.6290.14.camel@ignacio.lan>
	<20050714205012.GA20299@nostromo.devel.redhat.com>
	<1121387466.6290.20.camel@ignacio.lan>
	<1121412635.6290.28.camel@ignacio.lan>
	<20050715155226.GA32637@nostromo.devel.redhat.com>
	<1121456842.10063.1.camel@ignacio.lan>
	<20050715210534.GD2895@nostromo.devel.redhat.com>
Message-ID: <1121463484.10063.16.camel@ignacio.lan>

On Fri, 2005-07-15 at 17:05 -0400, Bill Nottingham wrote:
> Ignacio Vazquez-Abrams (ivazquez at ivazquez.net) said: 
> > Apparently udev can't see them.
> > 
> > "The first thing you need to do is find a directory somewhere in /sys
> > that corresponds to your hardware, and includes a file named "dev", as
> > udevinfo can only work on directories of this type. These directories
> > are all found under either /sys/block or /sys/class - there is no point
> > looking anywhere else!"
> > 
> > User-mode drivers don't give the device a block or class designator, and
> > so udev won't handle them.
> 
> Sure it will.
> 
> At the end of udev.rules:
> 
> ACTION=="add", SUBSYSTEM=="usb", MODALIAS=="*", \
>         RUN+="/sbin/modprobe $modalias"
> 
> This gets run for all usb devices to *try* and load a driver. It's running
> before the kernel could know whether or not a driver is kenrel or
> userspace.

Aha! That got it.

> Perhaps the udev docs need some help.

Indeed. The range of actions possible would also be useful.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/8f046128/attachment.sig>

From sundaram at redhat.com  Fri Jul 15 21:36:59 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 03:06:59 +0530
Subject: No more right click terminal
In-Reply-To: <20050715212743.GH954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<1121274056.10565.15.camel@nexus.verbum.private>	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>	<1121462167.4036.32.camel@nexus.verbum.private>	<20050715211752.GE954722@hiwaay.net>	<Pine.LNX.4.58.0507151719590.10424@devserv.devel.redhat.com>
	<20050715212743.GH954722@hiwaay.net>
Message-ID: <42D82C7B.7090706@redhat.com>

Hi

>SSH is a tool for anyone that wants to access a remote system.
>
>Haven't you people ever heard of web hosting?  We've got a several
>thousand customers, and many of them prefer to edit their web sites on
>the server, especially since transferring things back and forth is slow,
>cumbersome, and sometimes troublesome to keep in sync.  There are tools
>to make that easier (such as rsync, another terminal program), but it is
>much easier for many people to simply have one copy of their web site on
>the server.
>
>  
>
Since I used to work for one during system administration for a couple 
of years, I know that the end users without a good knowledge of the 
command line as Linux/Unix users never actually preferred to use SSH 
unless which was  largely controlled through web hosting control panels 
administrated through a web interface.  Large majority who were forced 
to use SSH preferred something like putty to launch a SSH instead of 
demanding that the desktop context menu should contain a terminal option 
by default.

regards
Rahul



From nmiell at comcast.net  Fri Jul 15 21:47:59 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Fri, 15 Jul 2005 14:47:59 -0700
Subject: No more right click terminal
In-Reply-To: <20050715213359.GI954722@hiwaay.net>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<1121462915.2946.1.camel@localhost.localdomain>
	<20050715213359.GI954722@hiwaay.net>
Message-ID: <1121464079.2946.3.camel@localhost.localdomain>

On Fri, 2005-07-15 at 16:33 -0500, Chris Adams wrote:
> Once upon a time, Nicholas Miell <nmiell at comcast.net> said:
> > On Fri, 2005-07-15 at 16:17 -0500, Chris Adams wrote:
> > > Let me know when you invent a GUI SSH.
> > 
> > It's called rdesktop/vnc/Xnest + tsclient.
> 
> Not on my shared hosting servers it isn't.  I'm not going to run a bunch
> of copies of X so users that can figure out VNC can avoid SSH.

Well, no. Hosting servers would run WebDAV.

-- 
Nicholas Miell <nmiell at comcast.net>



From seyman at wanadoo.fr  Fri Jul 15 21:03:34 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 15 Jul 2005 23:03:34 +0200
Subject: No more right click terminal
In-Reply-To: <42D8079F.4030204@warmcat.com>
References: <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<20050715140354.GB10161@srv01.cluenet.de>
	<604aa791050715080950042ef5@mail.gmail.com>
	<42D7D640.6020607@warmcat.com>
	<604aa79105071509037054f9f1@mail.gmail.com>
	<42D7E57E.3030706@warmcat.com>
	<20050715172024.GG19895@chrys.ms.mff.cuni.cz>
	<42D8079F.4030204@warmcat.com>
Message-ID: <20050715210334.GA6037@orient.maison.moi>

On Fri, Jul 15, 2005 at 07:59:43PM +0100, Andy Green wrote:
> 
> It's an RPM, same format as everything else, contains normal files,
> encapsulates an external .tar.gz compilable project, and contains
> deviations from upstream mandated by Redhat like other packages do.

The number of patches in the kernel rpm has been divided by 3 or 4
(Dave, exact numbers?) since Fedora's inception.

Emmanuel



From seyman at wanadoo.fr  Fri Jul 15 21:59:04 2005
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Fri, 15 Jul 2005 23:59:04 +0200
Subject: No more right click terminal
In-Reply-To: <1121462180.8029.30.camel@prometheus.gamehouse.com>
References: <604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
Message-ID: <20050715215904.GA6694@orient.maison.moi>

On Fri, Jul 15, 2005 at 02:16:20PM -0700, Jesse Keating wrote:
> 
> By sending it upstream, all you're doing is sending the 'explosion'
> somewhere else to be ignored.  I'm not saying every single complaint has
> to be addressed, but when a large contingency of users have issues with
> something, perhaps then it is time to step up and be the champion for
> the userbase.

If you're only fixing things for a single distribution, the numbers
of users cannot be considered 'large'.

Emmanuel



From jspaleta at gmail.com  Fri Jul 15 22:05:10 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 18:05:10 -0400
Subject: No more right click terminal
In-Reply-To: <1121462180.8029.30.camel@prometheus.gamehouse.com>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
Message-ID: <604aa79105071515053d280939@mail.gmail.com>

On 7/15/05, Jesse Keating <jkeating at j2solutions.net> wrote:
> By sending it upstream, all you're doing is sending the 'explosion'
> somewhere else to be ignored.  

The sentence has the underlying assumption that explosions will be
ignored regardless of whether they are. If you really believe that,
then you would be advocating avoding explosions instead of encouraging
them.  But instead you are advocating that explosions are prefectly
acceptable downstream in an effort to make downstream maintainers do
your bidding. That's not going to work.
  
> I'm not saying every single complaint has
> to be addressed, but when a large contingency of users 

Prove to me that the complaints about the terminal represent a large
contingent of fedora's userbase.  I claim you and everyone else in
this thread represent a vocal minority of the fedora userbase as well
as the gnome userbase more generally. Prove me wrong.
If you want to show gnome developers there is a "large" contigent of
the gnome userbase who have the same complaint.. drive it
upstream..with organized numbers that can actually be considered
"large" across distributions.  I look forward to signing your
petition.

-jef"Case D: you fire off so many redudant complaints in the
downstream list that downstream maintainers and developers tune the
list out completely in an effort to avoid the noise."spaleta



From jkeating at j2solutions.net  Fri Jul 15 22:26:46 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 15:26:46 -0700
Subject: No more right click terminal
In-Reply-To: <20050715215904.GA6694@orient.maison.moi>
References: <604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<20050715215904.GA6694@orient.maison.moi>
Message-ID: <1121466406.23344.10.camel@prometheus.gamehouse.com>

On Fri, 2005-07-15 at 23:59 +0200, Emmanuel Seyman wrote:
> If you're only fixing things for a single distribution, the numbers
> of users cannot be considered 'large'.
> 

Likewise an individual's voice on a medium such as Gnome lists is going
to be very very very small, and easily ignorable.  However when a very
well known distribution steps in and says "Well, the majority of _OUR_
users don't really like this, can we discuss some more" it bears a bit
more weight.

-- 
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



From dr at cluenet.de  Fri Jul 15 22:26:17 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 00:26:17 +0200
Subject: No more right click terminal
In-Reply-To: <1121459914.25236.26.camel@localhost.localdomain>
References: <604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
Message-ID: <20050715222617.GB14049@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 02:38:34PM -0600, Stuart Jansen wrote:
> Your influence is directly proportional to the value of your
> contribution--and talk is cheap.

Wrong. Read: http://www.fedora.redhat.com/about/leadership.html

Red Hat has the ultimate influence. Red Hat pays the folks putting
Fedora together. There is no "community thang". It's Red Hat plus
a few hand-selected outside supporters. Especially look at the chapter
"Voting".

After all, things happen the way Red Hat wants it. There's nothing wrong
about it, but please stop this "community" marketing then. And given
recent dominant communication by some Red Hat folks and... uhm...
close associates, Red Hat doesn't want to hear about what the user
base wants... the user base should tell upstream. That's IMHO against
the "we seek rough consensus"... at least if "we" does include more than
Red Hat internal cube-to-cube talks and perhaps some limited discussion
with outsiders in a read-only mailing list upon invitation (or
whatever).

My only chance is to discuss those fundamental problems in order to
try moving things into a better (for the user at least) direction. I
don't have the time nor knowledge nor energy for more. Linux & Fedora is
for sure not my main hobby anymore, nor my profession. It is a tool with
which I try to do my job and follow my hobbies. If this tool starts
diverting from me needs too much, I try to communicate this to the vendor
of the tool. They can either accept this constructive criticism
(remember: constructiveness is NOT defined by attached patch, but by
having a possible solution path provided, at least describing in detail
what's wrong) and try to do something about it, or they can say "we
don't care, go away". If the distro vendor cares about the users, he
won't say the latter.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From sundaram at redhat.com  Fri Jul 15 22:26:36 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 03:56:36 +0530
Subject: No more right click terminal
In-Reply-To: <1121466406.23344.10.camel@prometheus.gamehouse.com>
References: <604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<20050715215904.GA6694@orient.maison.moi>
	<1121466406.23344.10.camel@prometheus.gamehouse.com>
Message-ID: <42D8381C.8060306@redhat.com>

Hi

>Likewise an individual's voice on a medium such as Gnome lists is going
>to be very very very small, and easily ignorable.  However when a very
>well known distribution steps in and says "Well, the majority of _OUR_
>users don't really like this, can we discuss some more" it bears a bit
>more weight.
>  
>
How do you determine that the majority is telling this?. Do we want to 
concentrate on existing users or do we want to improve on it to adopt 
new ground?

regards
Rahul



From bart.vanbrabant at zoeloelip.be  Fri Jul 15 22:30:04 2005
From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant)
Date: Sat, 16 Jul 2005 00:30:04 +0200
Subject: Bootup delays
Message-ID: <42D838EC.1060402@zoeloelip.be>

Hello,

>From kernel 1432 and 1433 in rawhide my boot process has some serious
delays where my system doesn't seem to do anything and doesn't respond.
This also happens when logining in and starting gnome.
I made a bootchart from the 1426 kernel which runs fine and one form
1433 which suffers from those delays.
http://files.zoeloelip.be/1426.png
http://files.zoeloelip.be/1433.png


Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/f055d666/attachment.sig>

From rms at 1407.org  Fri Jul 15 22:32:47 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 15 Jul 2005 23:32:47 +0100
Subject: No more right click terminal
In-Reply-To: <1121462167.4036.32.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
Message-ID: <1121466767.2914.18.camel@roque>

On Fri, 2005-07-15 at 17:16 -0400, Colin Walters wrote:
> > Terminals should not be thought of as power-users only; they're useful
> > for everybody.
> 
> Completely, totally disagree.  Every time a non-developer/non-sysadmin
> has to use the terminal for something is a bug.

This is the most <censored/> argument I've seen on this thread.

http://www.linuxcommand.org/learning_the_shell.php

Any argument derived from this logic is totally absurd.
Non-shell usage for many things typically involves an amount of user
action AND knowledge several times bigger.

There's nothing hard on the following requirement:
   edit a text file with well documented comments to change preferences.

A text file configuration has all those things that until now no GUI
developer has ever been able to bring about, like finding a certain
configuration option, for instance.

And I don't mean "use vi" as a principle.

Just remember one of GUI's main functions: people, who haven't yet a
developed enough level of abstraction (due to age, intellect, etc...)

> Autocad is a very specialized tool for a particular audience.  You can
> probably assume that most of its users spend 8 hours a day for years in
> front of it and that any time they can save helps a lot.

What you say is actually true for more and more of "office" jobs.

What saves more time:
  a simple alias that disguises an ldapsearch command (like "phone
Someone")
or
  opening an ldap client (like some MUAs) clicking the right button then
locating "Someone"?

My gf works at a Portuguese "k-mart"-style shop, in the office, and the
stories I hear... so frequently they would improve a thousandfold their
performance should they use some simple combinations of TEXT USER
INTERFACE commands... a pity they use Windows...


OOPS! Main pattern here: commands suck, UI rules
			=> this is true in BAD operating systems

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/c37f6730/attachment.sig>

From rms at 1407.org  Fri Jul 15 22:35:48 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 15 Jul 2005 23:35:48 +0100
Subject: No more right click terminal
In-Reply-To: <1121463230.4036.42.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<1121462356.4036.34.camel@nexus.verbum.private>
	<20050715212427.GF954722@hiwaay.net>
	<1121463230.4036.42.camel@nexus.verbum.private>
Message-ID: <1121466948.2914.22.camel@roque>

On Fri, 2005-07-15 at 17:33 -0400, Colin Walters wrote:
> Or:
> 
> - Use a web page editing tool which knows how to invoke ssh or ftp or
>   webdav or whatever?

Right... bring huge file, alter locally, upload it again.

> Note that one could use GEdit (since it supports SFTP via gnome-vfs) as
> a basic web page editing tool now if we just fixed the bug that it
> refuses to save files over gnome-vfs (because the maintainers are on
> crack).

Same as above.

> > Also, since there's no way to set SELinux attributes via FTP or SFTP,
> > the only way to do so is via ssh.
> 
> Yes, that's a bug.  One I personally want to see fixed (for SFTP at
> least).

Easy to say, as the saying goes. Why should it ever be a "fix" on SSH?
Why is that a supposed function? Makes no sense. A remote system might
not even have acls and selinux attributes usually require relabelling...

> > And these are _not_ just system administrator things; we've got a few
> > thousand users that do things like this 
> 
> Right, but what you are doing is working around the lack of a good web
> page editing tool, which is a bug.

Sorry, I have to call for the BS flag.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/80e0a1be/attachment.sig>

From rms at 1407.org  Fri Jul 15 22:37:33 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 15 Jul 2005 23:37:33 +0100
Subject: No more right click terminal
In-Reply-To: <1121464079.2946.3.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<20050715211752.GE954722@hiwaay.net>
	<1121462915.2946.1.camel@localhost.localdomain>
	<20050715213359.GI954722@hiwaay.net>
	<1121464079.2946.3.camel@localhost.localdomain>
Message-ID: <1121467053.2914.24.camel@roque>

On Fri, 2005-07-15 at 14:47 -0700, Nicholas Miell wrote:
> On Fri, 2005-07-15 at 16:33 -0500, Chris Adams wrote:
> > Once upon a time, Nicholas Miell <nmiell at comcast.net> said:
> > > On Fri, 2005-07-15 at 16:17 -0500, Chris Adams wrote:
> > > > Let me know when you invent a GUI SSH.
> > > 
> > > It's called rdesktop/vnc/Xnest + tsclient.
> > 
> > Not on my shared hosting servers it isn't.  I'm not going to run a bunch
> > of copies of X so users that can figure out VNC can avoid SSH.
> 
> Well, no. Hosting servers would run WebDAV.

So now WebDAV should know about SElinux, acls, Windows permissions,
et-all. The standard dies almost instantly.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/1bab562f/attachment.sig>

From jkeating at j2solutions.net  Fri Jul 15 22:48:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 15 Jul 2005 15:48:09 -0700
Subject: No more right click terminal
In-Reply-To: <42D8381C.8060306@redhat.com>
References: <604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<20050715215904.GA6694@orient.maison.moi>
	<1121466406.23344.10.camel@prometheus.gamehouse.com>
	<42D8381C.8060306@redhat.com>
Message-ID: <1121467689.23344.21.camel@prometheus.gamehouse.com>

On Sat, 2005-07-16 at 03:56 +0530, Rahul Sundaram wrote:
> How do you determine that the majority is telling this?. Do we want
> to 
> concentrate on existing users or do we want to improve on it to adopt 
> new ground?

Thats a hard question to answer.  Especially when some 'improvements'
can be viewed as quite the opposite.  I never said this was easy, nor
that I have all the answers.  I'm just dissatisfied with the way that
things are, and I'm such a loser I have no real good suggestions on how
to fix it.  Please feel free to ignore me.

-- 
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



From dr at cluenet.de  Fri Jul 15 22:43:07 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 00:43:07 +0200
Subject: No more right click terminal
In-Reply-To: <1121466406.23344.10.camel@prometheus.gamehouse.com>
References: <604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<20050715215904.GA6694@orient.maison.moi>
	<1121466406.23344.10.camel@prometheus.gamehouse.com>
Message-ID: <20050715224307.GC14049@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 03:26:46PM -0700, Jesse Keating wrote:
> On Fri, 2005-07-15 at 23:59 +0200, Emmanuel Seyman wrote:
> > If you're only fixing things for a single distribution, the numbers
> > of users cannot be considered 'large'.
> 
> Likewise an individual's voice on a medium such as Gnome lists is going
> to be very very very small, and easily ignorable.  However when a very
> well known distribution steps in and says "Well, the majority of _OUR_
> users don't really like this, can we discuss some more" it bears a bit
> more weight.

Jup. Exactly that. If Fedora would really be a community thing (which it
isn't), then we _would_ have a _welcomed_ discussion about controversial
issues, and _would_ have a voting in place when rough consensus can't be
found. But we don't. I'm having more and more the impression that what
the "community user base" wants is irrelevant. The only thing to the
contrary I see are the usual "Ideas for FCx?" postings by Red Hat at the
beginning of each release cycles.

Other than that, the prio is I guess:

a) what the RHEL customer base wants
b) what Red Hat prefers
c) uhm...
d) lets see...
g) what stupid whiners like me might want

Given that Red Hat finances all this here, that's perfectly fine. But
don't call it a community effort. And no, "allowing" outsiders to pick
up dropped-by-Red-Hat packages and market them as "Fedora Extras",
outsourcing the tedious job of maintaining older releases under the
Fedora brand (Fedora Legacy) or stuff like writing docs ("Release notes
authors wanted!") is not really "the community thang". It's getting rid
of excess work that is boring and doesn't translate at all to commercial
gains. After all, Fedora is Red Hat's playground to try new cool stuff
for RHEL. RHEL Beta sounds fishy. Fedora sounds way less fishy, and
much easier to swallow than asking mass folks to run "RHEL beta". :-)
[yes I know, RHEL Workstation is not directly derrived from Fedora,
so don't please don't start discussing over those kind of verbial
details]

I know I do risk to be considered being an ungrateful asshole. But
believe me, I'm just pissed by being ignored (and not just ME being
ignored) by something that markets itself aggressively as a community
thing which it isn't by my (and many other) standards. False marketing.

If those issues cannot be openly discussed, well, then I guess I can
abandon all hope. I would like to hear that from the folks who have the
real power over that though, not some... cheerleaders, rigerously
preaching the same mantras (the nice verbiage for "go away, we don't
care") again and again without actually listening to arguments.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From sundaram at redhat.com  Fri Jul 15 22:50:36 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 04:20:36 +0530
Subject: No more right click terminal
In-Reply-To: <20050715224307.GC14049@srv01.cluenet.de>
References: <604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<20050715215904.GA6694@orient.maison.moi>	<1121466406.23344.10.camel@prometheus.gamehouse.com>
	<20050715224307.GC14049@srv01.cluenet.de>
Message-ID: <42D83DBC.7080708@redhat.com>

Hi

>Jup. Exactly that. If Fedora would really be a community thing (which it
>isn't), then we _would_ have a _welcomed_ discussion about controversial
>issues, and _would_ have a voting in place when rough consensus can't be
>found. But we don't. I'm having more and more the impression that what
>the "community user base" wants is irrelevant. The only thing to the
>contrary I see are the usual "Ideas for FCx?" postings by Red Hat at the
>beginning of each release cycles.
>
Voting is really the wrong way to decide this since the voters naturally 
present skewed data not representative of typical end users. If we have 
to vote everytime someone flames the development list, development would 
pretty much stall but you dont have to rely on my words for it.   Like I 
said previously as an experiment, try convincing a distribution that you 
think  represents the community better that they should adopt a patch to 
bring in a option for terminal users by default.

regards
Rahul



From dr at cluenet.de  Fri Jul 15 22:53:46 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 00:53:46 +0200
Subject: No more right click terminal
In-Reply-To: <42D83DBC.7080708@redhat.com>
References: <604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<20050715215904.GA6694@orient.maison.moi>
	<1121466406.23344.10.camel@prometheus.gamehouse.com>
	<20050715224307.GC14049@srv01.cluenet.de>
	<42D83DBC.7080708@redhat.com>
Message-ID: <20050715225346.GD14049@srv01.cluenet.de>

On Sat, Jul 16, 2005 at 04:20:36AM +0530, Rahul Sundaram wrote:
> Voting is really the wrong way to decide this since the voters naturally 
> present skewed data not representative of typical end users.

Ah right. And you really know better what's good for the users then
the users who are able and willing to express themselves what they want.
Your view of what's right is of course much less skewed.

THAT is arrogance in purity.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From sundaram at redhat.com  Fri Jul 15 22:59:19 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 04:29:19 +0530
Subject: No more right click terminal
In-Reply-To: <20050715225346.GD14049@srv01.cluenet.de>
References: <604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<20050715215904.GA6694@orient.maison.moi>	<1121466406.23344.10.camel@prometheus.gamehouse.com>	<20050715224307.GC14049@srv01.cluenet.de>	<42D83DBC.7080708@redhat.com>
	<20050715225346.GD14049@srv01.cluenet.de>
Message-ID: <42D83FC7.3080500@redhat.com>

Daniel Roesen wrote:

>On Sat, Jul 16, 2005 at 04:20:36AM +0530, Rahul Sundaram wrote:
>  
>
>>Voting is really the wrong way to decide this since the voters naturally 
>>present skewed data not representative of typical end users.
>>    
>>
>
>Ah right. And you really know better what's good for the users then
>the users who are able and willing to express themselves what they want.
>Your view of what's right is of course much less skewed.
>
>THAT is arrogance in purity.
>
No. Not really. There is a pretty simple reason behind this. End users 
typically do not involve in those voting efforts.. We will have some 
advanced users voting in their choices which might represent some 
portion of the user base but we should be aiming towards new users. 
Democracy has never worked for any open source project.

regards
Rahul



From rms at 1407.org  Fri Jul 15 23:01:52 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Sat, 16 Jul 2005 00:01:52 +0100
Subject: No more right click terminal
In-Reply-To: <42D83FC7.3080500@redhat.com>
References: <604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<20050715215904.GA6694@orient.maison.moi>
	<1121466406.23344.10.camel@prometheus.gamehouse.com>
	<20050715224307.GC14049@srv01.cluenet.de>	<42D83DBC.7080708@redhat.com>
	<20050715225346.GD14049@srv01.cluenet.de> <42D83FC7.3080500@redhat.com>
Message-ID: <1121468512.2914.26.camel@roque>

On Sat, 2005-07-16 at 04:29 +0530, Rahul Sundaram wrote:
> Democracy has never worked for any open source project.

Arrogance neither.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/1eeb886d/attachment.sig>

From walters at redhat.com  Fri Jul 15 23:04:44 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 19:04:44 -0400
Subject: No more right click terminal
In-Reply-To: <20050715222617.GB14049@srv01.cluenet.de>
References: <604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
Message-ID: <1121468684.4036.57.camel@nexus.verbum.private>

On Sat, 2005-07-16 at 00:26 +0200, Daniel Roesen wrote:

> (remember: constructiveness is NOT defined by attached patch, but by
> having a possible solution path provided, 

What is wrong with the solution path provided with
nautilus-open-terminal?




From brent at linux.wku.edu  Fri Jul 15 23:11:20 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 18:11:20 -0500 (CDT)
Subject: No more right click terminal
In-Reply-To: <1121462167.4036.32.camel@nexus.verbum.private>
Message-ID: <Pine.LNX.4.44.0507151806430.17647-100000@linux>

On Fri, 15 Jul 2005, Colin Walters wrote:
> Completely, totally disagree.  Every time a non-developer/non-sysadmin
> has to use the terminal for something is a bug.

This is a very odd statement since one of the reasons that I was turned on
to Linux was that one of my teachers used to use a CLI command to figure
his entire class grades in one swoop.  He entered his grades into a text
file using vi and then had a command aliased that would figure everything
up for him.

It was about two lines long and contained various calls to awk/sed, cut,
grep, wc, sort and all kinds of other things.  If you were to tell him
that you expected him to do that in some kinda gui (like excel or OO) he
would flunk you from the class.  His point about the whole thing was that
he could type: grade_report semester2_class3.txt >
final_grade_semester2_class3.txt  and it would do everything for him in
less time than it took for Excel to open on his Windows machine that the
University gave him.

What exactly is the fastest way in a GUI to take the output of a file that
has all the grades for an entire class in it, figure everyone's grades,
separate them based upon email address, and then mail them individually
from a GUI, while also mailing them ALL to his Department head in like 10
seconds?

This is not a Linux Administrator either.  As a matter of fact he ask me
to help him set up his new network card in the machine like two months
later.  This was just a Unix user, that had learned the value and power of
the CLI.

Heck even MS is attempting to get the CLI involved in the OS again as
evidenced by their desire to come up with a CLI that is better than BASH.
They are attempting to emulate Linux because of the arguement that a lot
of people have for using it: "I like using Linux because I don't have to
know were every setting is in some GUI somewhere.  All I have to do is
edit a text file and that changes the settings slick and easy."  You are
advocating moving toward their current model, while they are moving toward
ours.

Regardless of how you get there (right click, application menu,
CTRL+ALT+F1) using the command line is NOT a bug.

Brent Norris




From sundaram at redhat.com  Fri Jul 15 23:12:45 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 04:42:45 +0530
Subject: No more right click terminal
In-Reply-To: <1121468512.2914.26.camel@roque>
References: <604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<20050715215904.GA6694@orient.maison.moi>	<1121466406.23344.10.camel@prometheus.gamehouse.com>	<20050715224307.GC14049@srv01.cluenet.de>	<42D83DBC.7080708@redhat.com>	<20050715225346.GD14049@srv01.cluenet.de>
	<42D83FC7.3080500@redhat.com> <1121468512.2914.26.camel@roque>
Message-ID: <42D842ED.5030001@redhat.com>

Rui Miguel Seabra wrote:

>On Sat, 2005-07-16 at 04:29 +0530, Rahul Sundaram wrote:
>  
>
>>Democracy has never worked for any open source project.
>>    
>>
>
>Arrogance neither.
>
>Rui
>
>  
>
Counter examples would be good. I am willing to learn
regards
Rahul



From walters at redhat.com  Fri Jul 15 23:15:07 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 19:15:07 -0400
Subject: No more right click terminal
In-Reply-To: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
Message-ID: <1121469308.4036.64.camel@nexus.verbum.private>

On Fri, 2005-07-15 at 18:11 -0500, Brent D. Norris wrote:
> On Fri, 15 Jul 2005, Colin Walters wrote:
> > Completely, totally disagree.  Every time a non-developer/non-sysadmin
> > has to use the terminal for something is a bug.
> 
> This is a very odd statement since one of the reasons that I was turned on
> to Linux was that one of my teachers used to use a CLI command to figure
> his entire class grades in one swoop.  He entered his grades into a text
> file using vi and then had a command aliased that would figure everything
> up for him.

When I was a TA, I used Gnumeric to keep track of grades.

> What exactly is the fastest way in a GUI to take the output of a file that
> has all the grades for an entire class in it, figure everyone's grades,
> separate them based upon email address, and then mail them individually
> from a GUI, while also mailing them ALL to his Department head in like 10
> seconds?

I in fact wrote a bash script to send grade mail as well (from the
exported gnumeric spreadsheet as text) but that's just because the
provided tool for grading sucked and was in tcl/tk and I didn't want to
touch it.  The university should be in the business of providing grading
tools; they shouldn't expect every TA to write their own. 




From sundaram at redhat.com  Fri Jul 15 23:16:47 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 04:46:47 +0530
Subject: No more right click terminal
In-Reply-To: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
Message-ID: <42D843DF.9000308@redhat.com>

Hi

>Regardless of how you get there (right click, application menu,
>CTRL+ALT+F1) using the command line is NOT a bug.
>
>  
>
Definitely not a bug. I use a terminal all the time too. 
Non-developer/non-sysadmin is the keyword to note here from Colin's argument

regards
Rahul



From josh at bluga.net  Fri Jul 15 23:20:31 2005
From: josh at bluga.net (Joshua Eichorn)
Date: Fri, 15 Jul 2005 16:20:31 -0700
Subject: No more right click terminal
In-Reply-To: <42D843DF.9000308@redhat.com>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
	<42D843DF.9000308@redhat.com>
Message-ID: <42D844BF.2090001@bluga.net>

Rahul Sundaram wrote:

> Hi
>
>> Regardless of how you get there (right click, application menu,
>> CTRL+ALT+F1) using the command line is NOT a bug.
>>
>>  
>>
> Definitely not a bug. I use a terminal all the time too. 
> Non-developer/non-sysadmin is the keyword to note here from Colin's 
> argument
>
> regards
> Rahul
>
If my mom every has to use the command line to do anything its a bug.  I 
get a phone call if the auto saving password cookie in gmail gets unset 
and she has to log in.

The terminal might be nice for us geeks, but its Scary to most users.

I mean just give it up, for most users the speed up a terminal gives is 
never worth it, 10 hours of training to use a terminal would never be 
made up in speed gains for most users.  And most users need a whole lot 
more then 10 hours of training.

-josh



From brent at linux.wku.edu  Fri Jul 15 23:37:34 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 18:37:34 -0500 (CDT)
Subject: No more right click terminal
In-Reply-To: <1121469308.4036.64.camel@nexus.verbum.private>
Message-ID: <Pine.LNX.4.44.0507151835060.17917-100000@linux>

> I in fact wrote a bash script to send grade mail as well (from the
> exported gnumeric spreadsheet as text) but that's just because the
> provided tool for grading sucked and was in tcl/tk and I didn't want to
> touch it.  The university should be in the business of providing grading
> tools; they shouldn't expect every TA to write their own.

So your argument is that even though this is what you did, it is still a
bug, and people should expect other people to write programs that do
things exactly the way that THEY the USER want it done.  Not to be a jerk,
because I was really just commenting on the use of the commandline, but
this is exactly what is happening _here_.  People are writing in saying
they want the program that other people are writing to do what they want,
and you are saying what they want is wrong.

Brent



From brent at linux.wku.edu  Fri Jul 15 23:40:28 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 18:40:28 -0500 (CDT)
Subject: No more right click terminal
In-Reply-To: <42D843DF.9000308@redhat.com>
Message-ID: <Pine.LNX.4.44.0507151837390.17917-100000@linux>

> Definitely not a bug. I use a terminal all the time too.
> Non-developer/non-sysadmin is the keyword to note here from Colin's argument

This was a teacher. Not a sysadmin.  This was a person that had learned
the value of the CLI and because of that they used it.  Saying that his
knowledge and use of the CLI is a wrong, just because he isn't a sysadmin
is (IMO) wrong.

There are a lot of things in this thread that are wrong and right (IMO),
but I think this statement that no one except Sysadmins and Developers
should use the CLI is just too wrong to let get by.

Brent



From sundaram at redhat.com  Fri Jul 15 23:37:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 05:07:58 +0530
Subject: No more right click terminal
In-Reply-To: <Pine.LNX.4.44.0507151837390.17917-100000@linux>
References: <Pine.LNX.4.44.0507151837390.17917-100000@linux>
Message-ID: <42D848D6.6030004@redhat.com>

Brent D. Norris wrote:

>>Definitely not a bug. I use a terminal all the time too.
>>Non-developer/non-sysadmin is the keyword to note here from Colin's argument
>>    
>>
>
>This was a teacher. Not a sysadmin.  This was a person that had learned
>the value of the CLI and because of that they used it.  Saying that his
>knowledge and use of the CLI is a wrong, just because he isn't a sysadmin
>is (IMO) wrong.
>
>There are a lot of things in this thread that are wrong and right (IMO),
>but I think this statement that no one except Sysadmins and Developers
>should use the CLI is just too wrong to let get by.
>
>Brent
>  
>
Does this use case deserve a context menu entry on the desktop by 
default that isnt solved through a shortcut key or the 
nautilus-open-terminal extension. This is the question we should be 
trying to answer here

regards
Rahul



From brent at linux.wku.edu  Fri Jul 15 23:46:08 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 18:46:08 -0500 (CDT)
Subject: No more right click terminal
In-Reply-To: <42D844BF.2090001@bluga.net>
Message-ID: <Pine.LNX.4.44.0507151840370.17917-100000@linux>

> If my mom every has to use the command line to do anything its a bug.  I
> get a phone call if the auto saving password cookie in gmail gets unset
> and she has to log in.
>
> The terminal might be nice for us geeks, but its Scary to most users.
>
> I mean just give it up, for most users the speed up a terminal gives is
> never worth it, 10 hours of training to use a terminal would never be
> made up in speed gains for most users.  And most users need a whole lot
> more then 10 hours of training.

Not to be mean (seriously, no your momma joke here), but just because your
mom can't understand these things and doesn't want to use them doesn't
mean there aren't _normal_ everyday users that want to.  There are normal
users that want to use the text based publishing languages, should they
stop using those and be forced to use Scribus instead?

CLI has lots of uses.  The power of | and > are enough in my opinion to
prove that, and there are lots of uses for those beyond system admin and
developer.

Brent



From brent at linux.wku.edu  Fri Jul 15 23:47:57 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 18:47:57 -0500 (CDT)
Subject: No more right click terminal
In-Reply-To: <42D848D6.6030004@redhat.com>
Message-ID: <Pine.LNX.4.44.0507151846320.17917-100000@linux>

> Does this use case deserve a context menu entry on the desktop by
> default that isnt solved through a shortcut key or the
> nautilus-open-terminal extension. This is the question we should be
> trying to answer here

I agree, and no I don't really think so (just my opinion), but I do think
the statement that no one should use the CLI is just too incorrect to let
slide in an effort to let this thread die.

Brent

sorry for the static.



From josh at bluga.net  Fri Jul 15 23:44:23 2005
From: josh at bluga.net (Joshua Eichorn)
Date: Fri, 15 Jul 2005 16:44:23 -0700
Subject: No more right click terminal
In-Reply-To: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
Message-ID: <42D84A57.2050604@bluga.net>

Brent D. Norris wrote:

>>If my mom every has to use the command line to do anything its a bug.  I
>>get a phone call if the auto saving password cookie in gmail gets unset
>>and she has to log in.
>>
>>The terminal might be nice for us geeks, but its Scary to most users.
>>
>>I mean just give it up, for most users the speed up a terminal gives is
>>never worth it, 10 hours of training to use a terminal would never be
>>made up in speed gains for most users.  And most users need a whole lot
>>more then 10 hours of training.
>>    
>>
>
>Not to be mean (seriously, no your momma joke here), but just because your
>mom can't understand these things and doesn't want to use them doesn't
>mean there aren't _normal_ everyday users that want to.  There are normal
>users that want to use the text based publishing languages, should they
>stop using those and be forced to use Scribus instead?
>
>CLI has lots of uses.  The power of | and > are enough in my opinion to
>prove that, and there are lots of uses for those beyond system admin and
>developer.
>
>Brent
>
>  
>
Where in there conversation anywhere did anyone every say no one should 
every use the cli again.

Yep it never happened.

What was said, was if someone like my mom has to us the cli to solve a 
problem its a bug.

They also said we should remove the content menu to get to the terminal 
cause it scares people like my mom.
Who btw outnumber technical users by a large amount, and are the large 
reason why stores like best buy and comp usa sell lots of computers 
running windows.

Now whats so bad about removing the context menu, you can put it back 
using already written software that even has extra features.
Its just a matter of getting it packaged and added to extras.

This argument became pointless a long time ago, but at least look at the 
real issue, instead of pretending someone is trying to take your 
terminal away.
-josh



From dr at cluenet.de  Fri Jul 15 23:44:57 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 01:44:57 +0200
Subject: No more right click terminal
In-Reply-To: <1121468684.4036.57.camel@nexus.verbum.private>
References: <604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
Message-ID: <20050715234457.GA15818@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 07:04:44PM -0400, Colin Walters wrote:
> > (remember: constructiveness is NOT defined by attached patch, but by
> > having a possible solution path provided, 
> 
> What is wrong with the solution path provided with
> nautilus-open-terminal?

That it is again another PACKAGE to implement a simple entry in the
right-click menu. And as far as I've read, it tries to do "a whole lot
more".

People here just want to start a shell window as effectively as
possible, as it's their main tool working with the desktop systems all
day (and no, it's not a very special application like Audio Editing
suite). Asking people to install another package (first they have to know
that it actually exists and how it's named - IIRC someone else pointed
out this very obvious way) for something that simple is ridiculous.

The path I could live with would be an option somewhere (not too hidden)
to enable the "Open Terminal" option again. For whatever's sake, disable
it by default, if you really think you need to hide essential tools to
get things done very effectively from users if you think they aren't
intellectually ready for that.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From toshio at tiki-lounge.com  Fri Jul 15 23:48:29 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 15 Jul 2005 19:48:29 -0400
Subject: No more right click terminal
In-Reply-To: <604aa79105071510543232b412@mail.gmail.com>
References: <1121248417.16074.19.camel@goose>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
	<604aa79105071410036bc73ee@mail.gmail.com>
	<1121447668.3128.23.camel@localhost>
	<604aa79105071510543232b412@mail.gmail.com>
Message-ID: <1121471309.3128.56.camel@localhost>

On Fri, 2005-07-15 at 13:54 -0400, Jeff Spaleta wrote:
> On 7/15/05, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> > I'm prepared to accept that.  Don't think I'm prepared to support it
> > though.  These are ideas to encourage people about the community aspect
> > of Fedora.  Is banning people something that supports or discourages
> > community?  
> 
> You said everyone needs to agree on respecting a boilerplate offtopic
> post.  If people are expected to respect that boilerplate and stop
> posting.. then i think its perfectly reasonable to espect that people
> who dont respect that boilerplate response to be warned and if they
> are habitual abusers asked to leave because they have disrespected
> established agreed apun rules of conduct for the list.  If the
> boilerplate offtopic response can't be relied on to move the
> discussion... I don't see the point really in creating or using that
> boilerplate response.
> 
Do you drive faster than the speed limit if you feel it's safe?  Either
the boilerplate answer will make sense to people and they'll obey it or
they'll feel it's illogical and reply until you ban them and engender
more ill will among those who feel the post was on-topic.

My position is that a polite boiler can keep a lot of these sprawling,
accusatory threads from spiralling so far.  But preventing it through
fear of punishment is the point at which making fedora-devel a better
environment for development starts conflicting with presenting fedora as
an open community project.

> > I think the first impression will be similar to the
> > -maintainers first impression.  Could even be worse unless we set up a
> > parallel fedora-devel-readonly list.  And what about redhat personnel?
> 
> moderation for fedora-devel has been suggested repeatedly to me and in
> the past i have always fought against it. At this point I frankly
> don't care to fight the suggestion any longer. Now that maintainers is
> open as a tool for contributors, the -devel list has lost much of its
> relevancy as a useful tool among contributors... I'm no longer going
> to make the effort to encourage better signal to noise here.  From now
> on, I'm just looking for ideas I agree with and will help make sure
> those ideas make it to the right people.
>  
If the noise is too high and useful discussion comes to occur only on
-maintainers then moderation and banning on -devel is pretty pointless.
If maintaining a good signal:noise ratio on -devel is desired then we'll
have to try voluntary measures first and then try and figure out how bad
the problem still is.

> > One of the original Fedora openness requirements was that discussion was
> > to take place on the fedora-devel list.  Can they be banned?
> 
> Acceptable use policies can still apply to open lists. If everyone
> participating is suppose to agree to respect the boilerplate response
> you proposed that I think its perfectly reasonable to enforce that
> agreement on pain of death.
> 
Contractually, I agree with you.  Perceptually I think it sends the
message that Fedora is courting a community of yes-men.

> > I think banning people is somewhat of a different topic.
> 
> Shrug, feel free to create the boilerplate and use it as you see fit.
> I fully expect certain people to ignore the boilerplate and to
> continue to discuss the material you deemed as off topic.
> 
I expect it too.  But I expect certain others to respect it.  If it cuts
50% of the posts to a thread like this we'll save a hundred messages a
month.

> Right now, my best understanding is that sabayon is meant to fill this
> niche on simplifying how to move a user from defaults to one of a
> number of different profile configurations. I don't know if you can
> easily pull in sabayon profile definitions from one box to another..
> or what it would take to pre-package a profile in an rpm in extras. 
> Something to talk to the sabayon developers about.  It certaintly
> seems like there should be a way to easily trade sabayon profiles
> across machines.
> 
> -jef"sabayon profiles.. collect them all!"spaleta
> 
I agree.  I'll grab the package and we'll see what it can do!

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/3e44e1d3/attachment.sig>

From sundaram at redhat.com  Fri Jul 15 23:50:39 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 05:20:39 +0530
Subject: No more right click terminal
In-Reply-To: <20050715234457.GA15818@srv01.cluenet.de>
References: <604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715201537.GA14049@srv01.cluenet.de>	<1121459914.25236.26.camel@localhost.localdomain>	<20050715222617.GB14049@srv01.cluenet.de>	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
Message-ID: <42D84BCF.9000502@redhat.com>

Hi

>That it is again another PACKAGE to implement a simple entry in the
>right-click menu. And as far as I've read, it tries to do "a whole lot
>more".
>
>  
>
Only if you obsolutely need a desktop context menu entry for the terminal


>People here just want to start a shell window as effectively as
>possible, as it's their main tool working with the desktop systems all
>day 
>
May I suggestion that such people add a icon to their panel or use a 
shortcut to launch this?


>The path I could live with would be an option somewhere (not too hidden)
>to enable the "Open Terminal" option again. For whatever's sake, disable
>it by default, 
>
Seems faily reasonable if the current architecture allows that.

Colin, how difficult is this to implement?

regards
Rahul



From ben.steeves at gmail.com  Fri Jul 15 23:52:48 2005
From: ben.steeves at gmail.com (Ben Steeves)
Date: Fri, 15 Jul 2005 20:52:48 -0300
Subject: No more right click terminal
In-Reply-To: <1121458841.8029.22.camel@prometheus.gamehouse.com>
References: <1121272795.13335.18.camel@localhost.localdomain>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
Message-ID: <7ebb24d10507151652431d6884@mail.gmail.com>

On 7/15/05, Jesse Keating <jkeating at j2solutions.net> wrote:
 
> End result?  Community and target users do see that maintainers care and
> listen and try for the end user's best interest.

More realistic end result: user of distro A complains to distro A
maintainer, but the maintainer doesn't think the user is right, a big
arguement ensues, wasting the maintainer and the user's time.  Other
users and maintainers chime in.  Pretty soon you're 70 posts into a
flamewar and no one can remember what the original complaint was
about.  User of distro B is so irate he flames maintainer of distro B
maintainer, who leaves the project in a fit of pique.  In distro C,
the user and the maintainer actually agree, but user C2 and C3
vehimently oppose.  Huge flamewar breaks out... etc.

Alternately, according to Case A, users A, B, C, C2, and C3 talk to
the upstream *developer*, avoid a mess on three distro's mailing
lists, don't piss off any maintainers, and maybe just maybe get their
pet feature implemented.

I can't understand how complaining to my coworkers about my taxes
hoping they'll write my MP is better than me writing my MP myself and
encouraging them to all do the same.  "Case B", as it were, makes
absolutely NO SENSE.
-- 
Ben Steeves                     _                    bcs at metacon.ca
 The ASCII ribbon campaign     ( )            ben.steeves at gmail.com
   against HTML e-mail          X                GPG ID: 0xB3EBF1D9
http://www.metacon.ca/bcs      / \     Yahoo Messenger: ben_steeves



From cmadams at hiwaay.net  Fri Jul 15 23:55:46 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 15 Jul 2005 18:55:46 -0500
Subject: No more right click terminal
In-Reply-To: <42D84A57.2050604@bluga.net>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
	<42D84A57.2050604@bluga.net>
Message-ID: <20050715235546.GB1014250@hiwaay.net>

Once upon a time, Joshua Eichorn <josh at bluga.net> said:
> What was said, was if someone like my mom has to us the cli to solve a 
> problem its a bug.

No, it has been stated repeatedly that a terminal is only useful for
developers and system administrators.  I agree that for someone to have
to use a terminal to fix a problem it is sub-optimal (I wouldn't say
bug).  However, even under Windows, there are a number things that are
easier or only possible from the command line (and our dialup/DSL
support people often ask customers to open a command line).

> They also said we should remove the content menu to get to the terminal 
> cause it scares people like my mom.

Can anyone cite a single case of this?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From stickster at gmail.com  Sat Jul 16 00:09:01 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 15 Jul 2005 20:09:01 -0400
Subject: No more right click terminal
In-Reply-To: <20050715234457.GA15818@srv01.cluenet.de>
References: <604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
Message-ID: <1121472541.3250.30.camel@localhost.localdomain>

On Sat, 2005-07-16 at 01:44 +0200, Daniel Roesen wrote:
> On Fri, Jul 15, 2005 at 07:04:44PM -0400, Colin Walters wrote:
> > > (remember: constructiveness is NOT defined by attached patch, but by
> > > having a possible solution path provided, 
> > 
> > What is wrong with the solution path provided with
> > nautilus-open-terminal?
> 
> That it is again another PACKAGE to implement a simple entry in the
> right-click menu. And as far as I've read, it tries to do "a whole lot
> more".

The "whole lot more" includes being able to right-click a folder and
open a terminal in that $PWD.

> People here just want to start a shell window as effectively as
> possible, as it's their main tool working with the desktop systems all
> day (and no, it's not a very special application like Audio Editing
> suite). Asking people to install another package (first they have to know
> that it actually exists and how it's named - IIRC someone else pointed
> out this very obvious way) for something that simple is ridiculous.

By "effective," don't you mean efficient?  All ways of opening a shell
are equally effective, assuming each way actually results in a shell
opening at all.  It either works or it doesn't; it's effective or it's
not.

If you wanted to start a shell as *efficiently* as possible, you
wouldn't use the GUI at all; you'd be working in a tty all day.  If you
*had* to use the GUI for some other reason, the most efficient way to
open a shell would be by assigning a keyboard shortcut.  The amount of
time it takes to move your hand away from the terminal -- where you're
probably working already, judging by the fact that it's your "main tool"
-- and then maneuver the mouse and click it twice is *MUCH GREATER* than
the amount of time it takes to hit Shift+Ctrl+T (for example).

> The path I could live with would be an option somewhere (not too hidden)
> to enable the "Open Terminal" option again. For whatever's sake, disable
> it by default, if you really think you need to hide essential tools to
> get things done very effectively from users if you think they aren't
> intellectually ready for that.

There are discussions taking place elsewhere about new methods for
combining useful packages in a meaningful way.  There is no reason
nautilus-open-terminal couldn't be a part of one of these combinations.
If you truly want to act constructively, and you're not willing or able
to convince the GNOME folks that this traditional shortcut is worth
retaining, then simply follow those discussions.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/9989d445/attachment.sig>

From dr at cluenet.de  Sat Jul 16 00:20:53 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 02:20:53 +0200
Subject: No more right click terminal
In-Reply-To: <42D84BCF.9000502@redhat.com>
References: <604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<42D84BCF.9000502@redhat.com>
Message-ID: <20050716002053.GB15818@srv01.cluenet.de>

On Sat, Jul 16, 2005 at 05:20:39AM +0530, Rahul Sundaram wrote:
> >People here just want to start a shell window as effectively as
> >possible, as it's their main tool working with the desktop systems all
> >day 
> >
> May I suggestion that such people add a icon to their panel or use a 
> shortcut to launch this?

No. With that reasoning you can immediately scratch the right-click menu
alltogether. It carries such all-important used-all-the-time options
like "Change Desktop Background", "Create Launcher" etc. You can put
all that stuff elsewhere and use the right-click menu for stuff that's
REALLY used all the time by actual users.

> >The path I could live with would be an option somewhere (not too hidden)
> >to enable the "Open Terminal" option again. For whatever's sake, disable
> >it by default, 
>
> Seems faily reasonable if the current architecture allows that.

Perhaps thinking a step further makes sense, and making this menu
user-configurable, so people can add their fav tools right there.
This wouldn't only serve the very few terminal users out there who
suffer the lack of appropriate point-and-click tools, but also other
folks who regularily need to fire up apps and scripts.

Perhaps such an extension would even be accepted upstream. You know, to
serve all the other distros using GNOME. :-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From walters at redhat.com  Sat Jul 16 00:18:56 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 15 Jul 2005 20:18:56 -0400
Subject: No more right click terminal
In-Reply-To: <Pine.LNX.4.44.0507151835060.17917-100000@linux>
References: <Pine.LNX.4.44.0507151835060.17917-100000@linux>
Message-ID: <1121473136.4036.70.camel@nexus.verbum.private>

On Fri, 2005-07-15 at 18:37 -0500, Brent D. Norris wrote:
> > I in fact wrote a bash script to send grade mail as well (from the
> > exported gnumeric spreadsheet as text) but that's just because the
> > provided tool for grading sucked and was in tcl/tk and I didn't want to
> > touch it.  The university should be in the business of providing grading
> > tools; they shouldn't expect every TA to write their own.
> 
> So your argument is that even though this is what you did, it is still a
> bug, and people should expect other people to write programs that do
> things exactly the way that THEY the USER want it done.  

Yes, I think the general population should expect programmers to write
programs that don't suck.

> Not to be a jerk,
> because I was really just commenting on the use of the commandline, but
> this is exactly what is happening _here_. 

No one's advocating removing the commandline, it is definitely useful
for the people developing the applications.



From jspaleta at gmail.com  Sat Jul 16 00:27:12 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 15 Jul 2005 20:27:12 -0400
Subject: No more right click terminal
In-Reply-To: <1121471309.3128.56.camel@localhost>
References: <1121248417.16074.19.camel@goose>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi> <20050714125454.GC3984@redhat.com>
	<033401c58885$94407f90$b6491b31@td612671>
	<1121358709.4718.34.camel@localhost>
	<604aa79105071410036bc73ee@mail.gmail.com>
	<1121447668.3128.23.camel@localhost>
	<604aa79105071510543232b412@mail.gmail.com>
	<1121471309.3128.56.camel@localhost>
Message-ID: <604aa79105071517272726acc1@mail.gmail.com>

On 7/15/05, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> My position is that a polite boiler can keep a lot of these sprawling,
> accusatory threads from spiralling so far.  

I hope you are right...and i am wrong. 

> But preventing it through
> fear of punishment is the point at which making fedora-devel a better
> environment for development starts conflicting with presenting fedora as
> an open community project.

Even open forums can have published acceptable conduct policies. There
is nothing inherently contradictory with have enforcable rules of
conduct and openness. Whether or not expected conduct should cover
what we are talking about is a judgement. Certaintly more grotesque
and disrespectful behavior can be moderated out without rational
people getting up in arms about it, thankful we don't have that sort
of problem.

> Contractually, I agree with you.  Perceptually I think it sends the
> message that Fedora is courting a community of yes-men.

There are several things I could say in response to this, but in an
effort to keep from spawnning yet another flamewar I will refrain from
showing the extent that I disagree with several unspoken assumptions
made in that sentence and just be your yes-man and agree with you...
without threat of moderation.

Make sure you choose your volunteer group of boilerplate wielding
volunteers carefully. I've seen people still get offended by the use
of boilerplate simply because of a grudge against the person who
posted the boilerplate.

-jef



From sundaram at redhat.com  Sat Jul 16 00:31:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 06:01:58 +0530
Subject: No more right click terminal
In-Reply-To: <20050716002053.GB15818@srv01.cluenet.de>
References: <604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715201537.GA14049@srv01.cluenet.de>	<1121459914.25236.26.camel@localhost.localdomain>	<20050715222617.GB14049@srv01.cluenet.de>	<1121468684.4036.57.camel@nexus.verbum.private>	<20050715234457.GA15818@srv01.cluenet.de>	<42D84BCF.9000502@redhat.com>
	<20050716002053.GB15818@srv01.cluenet.de>
Message-ID: <42D8557E.2030502@redhat.com>

Hi

>No. With that reasoning you can immediately scratch the right-click menu
>alltogether. It carries such all-important used-all-the-time options
>like "Change Desktop Background", "Create Launcher" etc. You can put
>all that stuff elsewhere and use the right-click menu for stuff that's
>REALLY used all the time by actual users.
>  
>
What is really used that is more useful and in context to the desktop?

regards
Rahul



From dr at cluenet.de  Sat Jul 16 00:33:22 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 02:33:22 +0200
Subject: No more right click terminal
In-Reply-To: <1121472541.3250.30.camel@localhost.localdomain>
References: <604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
Message-ID: <20050716003322.GC15818@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 08:09:01PM -0400, Paul W. Frields wrote:
> > People here just want to start a shell window as effectively as
> > possible, as it's their main tool working with the desktop systems all
> > day (and no, it's not a very special application like Audio Editing
> > suite). Asking people to install another package (first they have to know
> > that it actually exists and how it's named - IIRC someone else pointed
> > out this very obvious way) for something that simple is ridiculous.
> 
> By "effective," don't you mean efficient?

Yes, sorry. English is unfortunately not my native language. :-Z

> If you wanted to start a shell as *efficiently* as possible, you
> wouldn't use the GUI at all; you'd be working in a tty all day.

No. As I need to have several shells visible side-by-side all the time,
and interact with Firefox and sometimes OpenOffice.

There is not just black and white. There are shades of grey, too. "Best
of both worlds" approach.

> If you *had* to use the GUI for some other reason, the most efficient
> way to open a shell would be by assigning a keyboard shortcut.

No, as that would conflict with the terminals, wouldn't it? So I would
need to move the mouse out of the application/terminal windows to have
the desktop getting input focus... OOPS, impossible with metacity! And

> The amount of
> time it takes to move your hand away from the terminal -- where you're
> probably working already, judging by the fact that it's your "main tool"
> -- and then maneuver the mouse and click it twice is *MUCH GREATER* than
> the amount of time it takes to hit Shift+Ctrl+T (for example).

Yes, but I need to grab the mouse anyway to position the new terminal
window where I need it. So my usual action to open a new terminal is
to grab the mouse, right-click, move a few pixels to the very first
option "Open Terminal", left-click, and then drag the window where it
needs to be. Beat this. You can't.

Now if metacity would actually pop the window ready-to-drag under the
mouse pointer (drop where it should be by left-click... you know, all
the stuff fvwm had many many years ago already), even that could be
optimized, as no mouse movement to fetch the newly popped up window (in
the left upper corner, where the average mouse movement necessariy is
max) would be necessary anymore.

So opening a new terminal would be:

- right click
- move mouse a millimeter
- left click
- move mouse to where the term/app should go
- left click

=> done. THAT is efficient. :-)


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dr at cluenet.de  Sat Jul 16 00:36:52 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 02:36:52 +0200
Subject: No more right click terminal
In-Reply-To: <42D8557E.2030502@redhat.com>
References: <20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<42D84BCF.9000502@redhat.com>
	<20050716002053.GB15818@srv01.cluenet.de>
	<42D8557E.2030502@redhat.com>
Message-ID: <20050716003652.GD15818@srv01.cluenet.de>

On Sat, Jul 16, 2005 at 06:01:58AM +0530, Rahul Sundaram wrote:
> >No. With that reasoning you can immediately scratch the right-click menu
> >alltogether. It carries such all-important used-all-the-time options
> >like "Change Desktop Background", "Create Launcher" etc. You can put
> >all that stuff elsewhere and use the right-click menu for stuff that's
> >REALLY used all the time by actual users.
>
> What is really used that is more useful and in context to the desktop?

Must it be in a context with the desktop to make sense? Only for
academic reasons, IMHO. Shells don't have much more to do with the
desktop than about any other application to get your real work done.

I don't know what users use most often that don't need to work all the
time with shells to accomplish their tasks efficiently. Thus I was
suggesting to make the first part of the right-click menu configurable.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dr at cluenet.de  Sat Jul 16 00:41:14 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 02:41:14 +0200
Subject: No more right click terminal
In-Reply-To: <20050716003652.GD15818@srv01.cluenet.de>
References: <1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<42D84BCF.9000502@redhat.com>
	<20050716002053.GB15818@srv01.cluenet.de>
	<42D8557E.2030502@redhat.com>
	<20050716003652.GD15818@srv01.cluenet.de>
Message-ID: <20050716004114.GE15818@srv01.cluenet.de>

On Sat, Jul 16, 2005 at 02:36:52AM +0200, Daniel Roesen wrote:
> On Sat, Jul 16, 2005 at 06:01:58AM +0530, Rahul Sundaram wrote:
> > >No. With that reasoning you can immediately scratch the right-click menu
> > >alltogether. It carries such all-important used-all-the-time options
> > >like "Change Desktop Background", "Create Launcher" etc. You can put
> > >all that stuff elsewhere and use the right-click menu for stuff that's
> > >REALLY used all the time by actual users.
> >
> > What is really used that is more useful and in context to the desktop?

Sorry, my english again:

> Must it be in a context with the desktop to make sense?

s/Must it be/Does it have to be/

> I don't know what users use most often that don't need to work all the
> time with shells to accomplish their tasks efficiently.

s/that don't need/who don't need/

I should really re-read my postings before sending them off, apologies.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From sundaram at redhat.com  Sat Jul 16 00:42:21 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 16 Jul 2005 06:12:21 +0530
Subject: No more right click terminal
In-Reply-To: <20050716003652.GD15818@srv01.cluenet.de>
References: <20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715201537.GA14049@srv01.cluenet.de>	<1121459914.25236.26.camel@localhost.localdomain>	<20050715222617.GB14049@srv01.cluenet.de>	<1121468684.4036.57.camel@nexus.verbum.private>	<20050715234457.GA15818@srv01.cluenet.de>	<42D84BCF.9000502@redhat.com>	<20050716002053.GB15818@srv01.cluenet.de>	<42D8557E.2030502@redhat.com>
	<20050716003652.GD15818@srv01.cluenet.de>
Message-ID: <42D857ED.4000100@redhat.com>

Hi

>Must it be in a context with the desktop to make sense?
>
Yes. When you click on something on the desktop you dont expect a random 
unrelated menu to pop out.

>I don't know what users use most often that don't need to work all the
>time with shells to accomplish their tasks efficiently. Thus I was
>suggesting to make the first part of the right-click menu configurable.
>  
>
Making it configurable is the easy opt-out option. Then you call really 
tell all the users to piss off because we made it configurable.  Dont 
get me wrong. I do see the value it in for some people. Making the 
defaults right is the hard part which is why we are having this huge 
flamewar^W discussions

regards
Rahul



From ben.steeves at gmail.com  Sat Jul 16 01:03:52 2005
From: ben.steeves at gmail.com (Ben Steeves)
Date: Fri, 15 Jul 2005 22:03:52 -0300
Subject: No more right click terminal
In-Reply-To: <20050716003322.GC15818@srv01.cluenet.de>
References: <604aa79105071406403094ff4c@mail.gmail.com>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
Message-ID: <7ebb24d1050715180315fec4e8@mail.gmail.com>

On 7/15/05, Daniel Roesen <dr at cluenet.de> wrote:
> > If you wanted to start a shell as *efficiently* as possible, you
> > wouldn't use the GUI at all; you'd be working in a tty all day.
> 
> No. As I need to have several shells visible side-by-side all the time,
> and interact with Firefox and sometimes OpenOffice.

Sorry, but what does that have to do with using a key combination to
open a new shell?  Gnome-terminal has tabs, and if they don't float
your boat, windows.  Metacity takes great pains not to open
overlapping windows, too.
 
> > If you *had* to use the GUI for some other reason, the most efficient
> > way to open a shell would be by assigning a keyboard shortcut.
> 
> No, as that would conflict with the terminals, wouldn't it? So I would
> need to move the mouse out of the application/terminal windows to have
> the desktop getting input focus... OOPS, impossible with metacity! And

I really think you should try this before dismissing it.  I have a key
combination (alt-esc, in case you're wondering), that I use to open a
new terminal.  It works no matter what application has focus.
 
> Yes, but I need to grab the mouse anyway to position the new terminal
> window where I need it.

Ummm... no you don't.  Open the new shell (with a key combination),
then use alt-F7 to move the window (with the cursor keys).

 So my usual action to open a new terminal is
> to grab the mouse, right-click, move a few pixels to the very first
> option "Open Terminal", left-click, and then drag the window where it
> needs to be. Beat this. You can't.

My, how inefficient!  

> Now if metacity would actually pop the window ready-to-drag under the
> mouse pointer (drop where it should be by left-click... you know, all
> the stuff fvwm had many many years ago already), even that could be
> optimized, as no mouse movement to fetch the newly popped up window (in
> the left upper corner, where the average mouse movement necessariy is
> max) would be necessary anymore.

Yes, one *could* add all that cruft into metacity, or one could just
use fvwm instead.  Or one could use the keybindings that are defaulted
into GNOME.

> So opening a new terminal would be:
> 
> - right click
> - move mouse a millimeter
> - left click
> - move mouse to where the term/app should go
> - left click
> 
> => done. THAT is efficient. :-)

Ugh, no.  That's horribly inefficent.  Efficient is:

- alt+esc: open new terminal
- alt+F6: put metacity into "move window" mode
- use shift & cursor keys to put the term/app where it should go
- start using the term/app

Very efficient, and no need to take my hands off the keyboard!

-- 
Ben Steeves                     _                    bcs at metacon.ca
 The ASCII ribbon campaign     ( )            ben.steeves at gmail.com
   against HTML e-mail          X                GPG ID: 0xB3EBF1D9
http://www.metacon.ca/bcs      / \     Yahoo Messenger: ben_steeves



From obi at unixkiste.org  Sat Jul 16 01:08:29 2005
From: obi at unixkiste.org (Stefan Held)
Date: Sat, 16 Jul 2005 03:08:29 +0200
Subject: No more right click terminal
In-Reply-To: <42D84BCF.9000502@redhat.com>
References: <604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de> <42D84BCF.9000502@redhat.com>
Message-ID: <1121476109.13988.4.camel@lt-sh.intern.pcservice.de>

Am Samstag, den 16.07.2005, 05:20 +0530 schrieb Rahul Sundaram:

> May I suggestion that such people add a icon to their panel or use a 
> shortcut to launch this?

The People in here had something like that, but then RedHat decided it
is kewl to have this funny theme with the funny new gnome look.

.oO( And i really ever thought it was mainstream )

Then i realized that nice right klick thing. Now i use a totaly
different wm not gnome any more. But what do you think do i most of the
times now? 

Right klick on my Desktop and wondering where this Funny Menu is.


-- 
 Stefan Held                    VI has only 2 Modes:
 obi at unixkiste.org              The first one is for beeping all the time, 
 IRCNet: Obi_Wan                the second destroys the text.   
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------
    GPG-Keyprint = EAF2 6A65 D102 F2DB 4970  2A67 455B 98F2 572C 3FA9


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/94fc2833/attachment.sig>

From dr at cluenet.de  Sat Jul 16 01:16:45 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 03:16:45 +0200
Subject: No more right click terminal
In-Reply-To: <42D857ED.4000100@redhat.com>
References: <20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<42D84BCF.9000502@redhat.com>
	<20050716002053.GB15818@srv01.cluenet.de>
	<42D8557E.2030502@redhat.com>
	<20050716003652.GD15818@srv01.cluenet.de>
	<42D857ED.4000100@redhat.com>
Message-ID: <20050716011645.GA16250@srv01.cluenet.de>

On Sat, Jul 16, 2005 at 06:12:21AM +0530, Rahul Sundaram wrote:
> >Must it be in a context with the desktop to make sense?
> >
> Yes. When you click on something on the desktop you dont expect a random 
> unrelated menu to pop out.

When I click somewhere on the desktop it means that I want something
right here right now. Raising a shell or another commonly used app is
a perfect example.

> Making it configurable is the easy opt-out option. Then you call really 
> tell all the users to piss off because we made it configurable.  Dont 
> get me wrong. I do see the value it in for some people. Making the 
> defaults right is the hard part which is why we are having this huge 
> flamewar^W discussions

We're not at personal attacks yet (I ignore Jeff's attempts to lower the
bar by provocation), so I still consider this an "involved discussion".
:-)

And yes, I fully agree with you that the discussion is necessary and
makes sense. Unlike some other folks who propagate "if it doesn't fit
you, go whining elsewhere but shut up here".


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From stickster at gmail.com  Sat Jul 16 01:18:54 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 15 Jul 2005 21:18:54 -0400
Subject: No more right click terminal
In-Reply-To: <20050716003322.GC15818@srv01.cluenet.de>
References: <604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
Message-ID: <1121476734.3014.17.camel@localhost.localdomain>

On Sat, 2005-07-16 at 02:33 +0200, Daniel Roesen wrote:
> On Fri, Jul 15, 2005 at 08:09:01PM -0400, Paul W. Frields wrote:
> > > People here just want to start a shell window as effectively as
> > > possible, as it's their main tool working with the desktop systems all
> > > day (and no, it's not a very special application like Audio Editing
> > > suite). Asking people to install another package (first they have to know
> > > that it actually exists and how it's named - IIRC someone else pointed
> > > out this very obvious way) for something that simple is ridiculous.
> > 
> > By "effective," don't you mean efficient?
> 
> Yes, sorry. English is unfortunately not my native language. :-Z

No apology necessary, I just wanted to make sure I understood you
correctly.

> > If you wanted to start a shell as *efficiently* as possible, you
> > wouldn't use the GUI at all; you'd be working in a tty all day.
> 
> No. As I need to have several shells visible side-by-side all the time,
> and interact with Firefox and sometimes OpenOffice.
> 
> There is not just black and white. There are shades of grey, too. "Best
> of both worlds" approach.

True.  One size does not fit all.  GNOME tries to fit most "general
users," for example.

> > If you *had* to use the GUI for some other reason, the most efficient
> > way to open a shell would be by assigning a keyboard shortcut.
> 
> No, as that would conflict with the terminals, wouldn't it? So I would
> need to move the mouse out of the application/terminal windows to have
> the desktop getting input focus... OOPS, impossible with metacity! And

Wrong.  But I will admit I typed the wrong key sequence below.  I have a
shortcut assigned to "Ctrl+Alt+T," not "Ctrl+Shift+T," which opens up a
new terminal tab.  No matter what I'm doing -- even in a terminal
already -- Ctrl+Alt+T opens up a new terminal.  I don't need to move the
mouse at all.

> > The amount of
> > time it takes to move your hand away from the terminal -- where you're
> > probably working already, judging by the fact that it's your "main tool"
> > -- and then maneuver the mouse and click it twice is *MUCH GREATER* than
> > the amount of time it takes to hit Shift+Ctrl+T (for example).
> 
> Yes, but I need to grab the mouse anyway to position the new terminal
> window where I need it. So my usual action to open a new terminal is
> to grab the mouse, right-click, move a few pixels to the very first
> option "Open Terminal", left-click, and then drag the window where it
> needs to be. Beat this. You can't.

Ctrl+Alt+T
Alt+F7 (move mode)
Shift+arrow (depending on location, tap a couple of times to shift
terminal to other side of screen)
Q.E.D.

Notwithstanding the above, I am responding only to your claim that the
right-click "Open Terminal" is the most efficient way to *open a
terminal.*  Now you're talking about moving it where you want it, which
has little to do with using nautilus-open-terminal.

> Now if metacity would actually pop the window ready-to-drag under the
> mouse pointer (drop where it should be by left-click... you know, all
> the stuff fvwm had many many years ago already), even that could be
> optimized, as no mouse movement to fetch the newly popped up window (in
> the left upper corner, where the average mouse movement necessariy is
> max) would be necessary anymore.

You keep getting further away from the argument at hand.  What metacity
does has nothing to do with this thread either.

> So opening a new terminal would be:
> 
> - right click
> - move mouse a millimeter
> - left click
> - move mouse to where the term/app should go
> - left click
> 
> => done. THAT is efficient. :-)

See above.

None of this precludes the use of nautilus-open-terminal.  You haven't
responded to the more relevant and important part of my post, which is
about getting nautilus-open-terminal included as part of a new package
combination, say for power users.  I'm sure it would be easier to simply
argue about who has to move their hands less, but it would also
certainly be less constructive and definitely less fruitful.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/60e3e936/attachment.sig>

From dr at cluenet.de  Sat Jul 16 01:26:28 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 03:26:28 +0200
Subject: No more right click terminal
In-Reply-To: <7ebb24d1050715180315fec4e8@mail.gmail.com>
References: <20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
	<7ebb24d1050715180315fec4e8@mail.gmail.com>
Message-ID: <20050716012628.GB16250@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 10:03:52PM -0300, Ben Steeves wrote:
> On 7/15/05, Daniel Roesen <dr at cluenet.de> wrote:
> > > If you wanted to start a shell as *efficiently* as possible, you
> > > wouldn't use the GUI at all; you'd be working in a tty all day.
> > 
> > No. As I need to have several shells visible side-by-side all the time,
> > and interact with Firefox and sometimes OpenOffice.
> 
> Sorry, but what does that have to do with using a key combination to
> open a new shell?  Gnome-terminal has tabs, and if they don't float
> your boat, windows.  Metacity takes great pains not to open
> overlapping windows, too.

Please actually read what I was replying to before jumping in.

> I really think you should try this before dismissing it.  I have a key
> combination (alt-esc, in case you're wondering), that I use to open a
> new terminal.  It works no matter what application has focus.

And now you're working with an application that needs this key
combination in your terminal, or in the application itself. What now?

> > Yes, but I need to grab the mouse anyway to position the new terminal
> > window where I need it.
> 
> Ummm... no you don't.  Open the new shell (with a key combination),
> then use alt-F7 to move the window (with the cursor keys).

It takes 4 seconds to move a window in Y axis and 6 seconds in X axis
here with that method. Moving window with cursor keys... sorry, don't
have time and nerve for that game. :-)

With the mouse I'm done in 1.5-2.5 seconds OVERALL.

> > So opening a new terminal would be:
> > 
> > - right click
> > - move mouse a millimeter
> > - left click
> > - move mouse to where the term/app should go
> > - left click
> > 
> > => done. THAT is efficient. :-)
> 
> Ugh, no.  That's horribly inefficent.  Efficient is:
> 
> - alt+esc: open new terminal
> - alt+F6: put metacity into "move window" mode
> - use shift & cursor keys to put the term/app where it should go
> - start using the term/app
> 
> Very efficient, and no need to take my hands off the keyboard!

I'm already in your step4 when you're still working your cursor keys.
Really. You won't beat left-hand-on-keyboard (for ALT to move the
window) and right-on-mouse raising and moving the term. :-)

The time it takes for your method to open up a new term and move it into
the right lower corner here takes TEN SECONDS. Mine takes less than two.
Try it. :-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dr at cluenet.de  Sat Jul 16 01:32:40 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 03:32:40 +0200
Subject: No more right click terminal
In-Reply-To: <1121473136.4036.70.camel@nexus.verbum.private>
References: <Pine.LNX.4.44.0507151835060.17917-100000@linux>
	<1121473136.4036.70.camel@nexus.verbum.private>
Message-ID: <20050716013240.GC16250@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 08:18:56PM -0400, Colin Walters wrote:
> No one's advocating removing the commandline, it is definitely useful
> for the people developing the applications.

Then how about moving gnome-terminal, xterm etc. to Extras? As you say,
if you have to use the shell it's a bug. And you also say Fedora isn't
aimed at "power users / developers" (however that is defined). So
logical consequence is that it shouldn't get installed by default, and
move to Extras.

And if USERS feel the urge to use the command line, they should file
bugzilla bugs. A no wait, they should go to... uhm... whomever they
think that should provide a colorful mousable alternative to whatever
they just wanted to to efficiently with a shell.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From brent at linux.wku.edu  Sat Jul 16 01:40:35 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 20:40:35 -0500 (CDT)
Subject: No more right click terminal
In-Reply-To: <42D857ED.4000100@redhat.com>
Message-ID: <Pine.LNX.4.44.0507152038510.18937-100000@linux>

> Yes. When you click on something on the desktop you dont expect a random
> unrelated menu to pop out.

You would if it was something that you had configured, which was what I
think he was talking about.

i.e. It doesn't have to be related to the desktop, because if you
configured it with the programs you want, you wouldn't expect it to have
desktop options in there.

Brent



From brent at linux.wku.edu  Sat Jul 16 01:43:32 2005
From: brent at linux.wku.edu (Brent D. Norris)
Date: Fri, 15 Jul 2005 20:43:32 -0500 (CDT)
Subject: No more right click terminal **PERSONAL**
In-Reply-To: <20050716013240.GC16250@srv01.cluenet.de>
Message-ID: <Pine.LNX.4.44.0507152042550.18989-100000@linux>

HAHAHAHAHAHAHAHAAH truely awesome.  You made me snort milk through my
nose.

Brent Norris (http://brentnorris.net)
Network Administrator, Edmonson County Schools

On Sat, 16 Jul 2005, Daniel Roesen wrote:

> On Fri, Jul 15, 2005 at 08:18:56PM -0400, Colin Walters wrote:
> > No one's advocating removing the commandline, it is definitely useful
> > for the people developing the applications.
>
> Then how about moving gnome-terminal, xterm etc. to Extras? As you say,
> if you have to use the shell it's a bug. And you also say Fedora isn't
> aimed at "power users / developers" (however that is defined). So
> logical consequence is that it shouldn't get installed by default, and
> move to Extras.
>
> And if USERS feel the urge to use the command line, they should file
> bugzilla bugs. A no wait, they should go to... uhm... whomever they
> think that should provide a colorful mousable alternative to whatever
> they just wanted to to efficiently with a shell.
>
>
> Regards,
> Daniel
>
>



From dr at cluenet.de  Sat Jul 16 01:41:42 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 03:41:42 +0200
Subject: No more right click terminal
In-Reply-To: <42D848D6.6030004@redhat.com>
References: <Pine.LNX.4.44.0507151837390.17917-100000@linux>
	<42D848D6.6030004@redhat.com>
Message-ID: <20050716014142.GD16250@srv01.cluenet.de>

On Sat, Jul 16, 2005 at 05:07:58AM +0530, Rahul Sundaram wrote:
> Does this use case deserve a context menu entry on the desktop by 
> default that isnt solved through a shortcut key or the 
> nautilus-open-terminal extension. This is the question we should be 
> trying to answer here

Uhm, nearly. I would reformulate a little bit:

Do we want to keep the (IMHO, YMMV) most efficient way to open a new
terminal readily available, or do we want to force all the regular
terminal users (which are MANY, IM_NS_HO) use other methods less
efficient or even install a whole additional package (that they have to
know of that it even exists, and how it's named) to get this
oh-so-scary-to-your-average-windows-user menu option "Open terminal"
back?

What is gained by removing the option, and what does it cost to add it
back later. Compare. For me, a clear case.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dr at cluenet.de  Sat Jul 16 01:54:57 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 16 Jul 2005 03:54:57 +0200
Subject: No more right click terminal
In-Reply-To: <1121476734.3014.17.camel@localhost.localdomain>
References: <20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
	<1121476734.3014.17.camel@localhost.localdomain>
Message-ID: <20050716015457.GE16250@srv01.cluenet.de>

On Fri, Jul 15, 2005 at 09:18:54PM -0400, Paul W. Frields wrote:
> > > By "effective," don't you mean efficient?
> > 
> > Yes, sorry. English is unfortunately not my native language. :-Z
> 
> No apology necessary, I just wanted to make sure I understood you
> correctly.

Yup, that's how I understood your intention too. I'm just curse
myself for such mistakes. :-)

> > There is not just black and white. There are shades of grey, too. "Best
> > of both worlds" approach.
> 
> True.  One size does not fit all.  GNOME tries to fit most "general
> users," for example.

Can you please describe those users? Please including statistical
evidence that this fits the Fedora(!) user base.

> Wrong.  But I will admit I typed the wrong key sequence below.  I have a
> shortcut assigned to "Ctrl+Alt+T," not "Ctrl+Shift+T," which opens up a
> new terminal tab.  No matter what I'm doing -- even in a terminal
> already -- Ctrl+Alt+T opens up a new terminal.  I don't need to move the
> mouse at all.

And what if the application running in the terminal needs to receive
those keypresses?

Keyboard shortcuts are always a difficult subject, as it's important
which application (desktop being one of them) receives it, or has
priority. Yes, compromises can be made. Still, I need to grab the mouse
anyway to quickly position the window exactly where I want it. The
ALT-F7 cursor-key movement (even with the Shift acceleration) doesn't
cut it at all (for me).

> Notwithstanding the above, I am responding only to your claim that the
> right-click "Open Terminal" is the most efficient way to *open a
> terminal.*  Now you're talking about moving it where you want it, which
> has little to do with using nautilus-open-terminal.

Well, it's the whole procedure to getting a new terminal ready for
action. That includes (to me) starting the terminal and positioning and
perhaps resizing it to what I want. I can never get to the speed of
using the mouse for that with keyboard functions. And I'm quite a quick
keyboard typist, I'm doing it since since literally infancy. :-)

> > Now if metacity would actually pop the window ready-to-drag under the
> > mouse pointer (drop where it should be by left-click... you know, all
> > the stuff fvwm had many many years ago already), even that could be
> > optimized, as no mouse movement to fetch the newly popped up window (in
> > the left upper corner, where the average mouse movement necessariy is
> > max) would be necessary anymore.
> 
> You keep getting further away from the argument at hand.  What metacity
> does has nothing to do with this thread either.

Indeed. I was fading away, thinking load how to even more speed up the
process and make the GUI more convenient.

> None of this precludes the use of nautilus-open-terminal.  You haven't
> responded to the more relevant and important part of my post, which is
> about getting nautilus-open-terminal included as part of a new package
> combination, say for power users.

I did, but probably in other responses to other folks. I think the idea
of a package to add such an IMHO essential triviality back to GNOME
is like asking for people to shop again for the gear shift handle after
buying a new car. It's just completely over the top, IMHO.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From stickster at gmail.com  Sat Jul 16 03:33:44 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 15 Jul 2005 23:33:44 -0400
Subject: No more right click terminal
In-Reply-To: <20050716015457.GE16250@srv01.cluenet.de>
References: <20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
	<1121476734.3014.17.camel@localhost.localdomain>
	<20050716015457.GE16250@srv01.cluenet.de>
Message-ID: <1121484824.3014.32.camel@localhost.localdomain>

On Sat, 2005-07-16 at 03:54 +0200, Daniel Roesen wrote:
> On Fri, Jul 15, 2005 at 09:18:54PM -0400, Paul W. Frields wrote:
> > None of this precludes the use of nautilus-open-terminal.  You haven't
> > responded to the more relevant and important part of my post, which is
> > about getting nautilus-open-terminal included as part of a new package
> > combination, say for power users.
> 
> I did, but probably in other responses to other folks. I think the idea
> of a package to add such an IMHO essential triviality back to GNOME
> is like asking for people to shop again for the gear shift handle after
> buying a new car. It's just completely over the top, IMHO.

Not that I could see from the rest of this thread.  New and possibly
better ways of organizing and exposing Extras packages are being
discussed on fedora-extras-list.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050715/2627e723/attachment.sig>

From notting at redhat.com  Sat Jul 16 04:10:39 2005
From: notting at redhat.com (Bill Nottingham)
Date: Sat, 16 Jul 2005 00:10:39 -0400
Subject: Bootup delays
In-Reply-To: <42D838EC.1060402@zoeloelip.be>
References: <42D838EC.1060402@zoeloelip.be>
Message-ID: <20050716041039.GB5755@nostromo.devel.redhat.com>

Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: 
> >From kernel 1432 and 1433 in rawhide my boot process has some serious
> delays where my system doesn't seem to do anything and doesn't respond.
> This also happens when logining in and starting gnome.
> I made a bootchart from the 1426 kernel which runs fine and one form
> 1433 which suffers from those delays.
> http://files.zoeloelip.be/1426.png
> http://files.zoeloelip.be/1433.png

Looks like there's a 30 second process of just insmod, unless it's grouping
them. If you could track down what driver is being silly, that could
help a lot.

Bill



From pnasrat at redhat.com  Sat Jul 16 04:17:54 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Sat, 16 Jul 2005 00:17:54 -0400
Subject: No more right click terminal
In-Reply-To: <20050716015457.GE16250@srv01.cluenet.de>
References: <20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
	<1121476734.3014.17.camel@localhost.localdomain>
	<20050716015457.GE16250@srv01.cluenet.de>
Message-ID: <1121487475.3236.44.camel@enki.eridu>

On Sat, 2005-07-16 at 03:54 +0200, Daniel Roesen wrote:

> I did, but probably in other responses to other folks. I think the idea
> of a package to add such an IMHO essential triviality back to GNOME
> is like asking for people to shop again for the gear shift handle after
> buying a new car. It's just completely over the top, IMHO.

At the end of the day the user shouldn't care about the packages in that
much depth. OK can we take a step back here - it's rawhide, things shift
about.

The relevant conversation here should have been:

Bill: Wow dude, like this is missing!!
Ted: Yes, my most excellent friend. That was way extraneous where it
was. However what we've done is, like, refactored it so it's like an
extension. Which means it's everywhere...
Bill: Most excellent! However it's not in the default rolling
configuration which is bogus.
Ted: Wow! I must package that immediately <air guitar>
Bill: Excellent! Get that in extras and tested then we'll rock it in
core....

We can easily shift a package from extras and add it to comps. Hell
that's what I'd recommend to do in this case and will lobby for.

I understand other concerns about governence, etc. Those need to be
raised, and I encourage that.  Lets just try and concentrate on each
thread in turn.

I'm pretty sure come FC5 you'll get the right click terminal - rawhide
is rough, lets just be excellent to each other and party on dude...

Paul



From pnasrat at redhat.com  Sat Jul 16 04:41:22 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Sat, 16 Jul 2005 00:41:22 -0400
Subject: ANN: anaconda yum migration testing
Message-ID: <1121488882.11796.6.camel@enki.eridu>

Over the next week as part of the work to try get anaconda installs
using yum I'm going to switch over to yum by default:

* nfs installs will use yum as a back end
* nfsiso installs will not be available

Other install methods will fall back on the old method of
depsolving/installing

Later in the week http/ftp installs will move to using yum as a back
end. Some work in install speed optimisation will be needed but at the
moment we are focussed on getting it working without.

Paul 



From mwiktowy at gmx.net  Sat Jul 16 05:42:01 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sat, 16 Jul 2005 01:42:01 -0400
Subject: No more right click terminal
In-Reply-To: <20050716013240.GC16250@srv01.cluenet.de>
References: <Pine.LNX.4.44.0507151835060.17917-100000@linux>
	<1121473136.4036.70.camel@nexus.verbum.private>
	<20050716013240.GC16250@srv01.cluenet.de>
Message-ID: <1121492521.4468.12.camel@localhost>

It is a thread like this that reminds me of the quote:

"University politics are vicious precisely because the stakes are so
small." - Henry Kissinger

Replace "University" with "Desktop Environment", "Text Editor" or "Video
Card" and you have pretty much 90% of the mailing list traffic covered.

... Sadly :[

/Mike



From ben.steeves at gmail.com  Sat Jul 16 06:18:36 2005
From: ben.steeves at gmail.com (Ben Steeves)
Date: Sat, 16 Jul 2005 03:18:36 -0300
Subject: No more right click terminal
In-Reply-To: <20050716012628.GB16250@srv01.cluenet.de>
References: <20050715195945.GA4432@orient.maison.moi>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
	<20050715222617.GB14049@srv01.cluenet.de>
	<1121468684.4036.57.camel@nexus.verbum.private>
	<20050715234457.GA15818@srv01.cluenet.de>
	<1121472541.3250.30.camel@localhost.localdomain>
	<20050716003322.GC15818@srv01.cluenet.de>
	<7ebb24d1050715180315fec4e8@mail.gmail.com>
	<20050716012628.GB16250@srv01.cluenet.de>
Message-ID: <7ebb24d1050715231878a7c0d0@mail.gmail.com>

On 7/15/05, Daniel Roesen <dr at cluenet.de> wrote:

> Please actually read what I was replying to before jumping in.

I've read every post in this "discussion", some with amusement, some
with incredulity.  Mostly with a mounting irritation.
 
> > I really think you should try this before dismissing it.  I have a key
> > combination (alt-esc, in case you're wondering), that I use to open a
> > new terminal.  It works no matter what application has focus.
> 
> And now you're working with an application that needs this key
> combination in your terminal, or in the application itself. What now?

*If* that were to happen (and it never has), I can quite easily remap
the key combo.
 
> > > Yes, but I need to grab the mouse anyway to position the new terminal
> > > window where I need it.
> >
> > Ummm... no you don't.  Open the new shell (with a key combination),
> > then use alt-F7 to move the window (with the cursor keys).
> 
> It takes 4 seconds to move a window in Y axis and 6 seconds in X axis
> here with that method. Moving window with cursor keys... sorry, don't
> have time and nerve for that game. :-)

Try pressing the shift key.

> > Very efficient, and no need to take my hands off the keyboard!
> 
> I'm already in your step4 when you're still working your cursor keys.
> Really. You won't beat left-hand-on-keyboard (for ALT to move the
> window) and right-on-mouse raising and moving the term. :-)
> 
> The time it takes for your method to open up a new term and move it into
> the right lower corner here takes TEN SECONDS. Mine takes less than two.
> Try it. :-)

Using shift, I can throw a window into any corner of the screen in no time.

The point is -- /there's more than one way to do it/, whatever /it/
is.  That's the beauty of Linux.  Taking examples to ridiculous
extremes doesn't help prove a point.

-- 
Ben Steeves                     _                    bcs at metacon.ca
 The ASCII ribbon campaign     ( )            ben.steeves at gmail.com
   against HTML e-mail          X                GPG ID: 0xB3EBF1D9
http://www.metacon.ca/bcs      / \     Yahoo Messenger: ben_steeves



From dimi at lattica.com  Sat Jul 16 06:34:00 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 16 Jul 2005 02:34:00 -0400
Subject: No more right click terminal
In-Reply-To: <604aa79105071515053d280939@mail.gmail.com>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
Message-ID: <1121495640.11210.107.camel@dimi>

On Fri, 2005-07-15 at 18:05 -0400, Jeff Spaleta wrote:
> Prove to me that the complaints about the terminal represent a large
> contingent of fedora's userbase.  I claim you and everyone else in
> this thread represent a vocal minority of the fedora userbase as well
> as the gnome userbase more generally. Prove me wrong.

Why not the other way: prove that there is a large number of people
_complaining_ about that menu. All my experiences, without fail, has
shown that menu to be highly enjoyed by all users: from completely
clueless to advanced.

Given all the discussion around this, it is clear that there is a
portion of the user base that care deeply about it. Where is the other
portion that was so badly inconvenienced by the button to outweigh
the pain that's been caused to folks that do use it? 

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From pjones at redhat.com  Sat Jul 16 06:50:40 2005
From: pjones at redhat.com (Peter Jones)
Date: Sat, 16 Jul 2005 02:50:40 -0400
Subject: No more right click terminal
In-Reply-To: <1121495640.11210.107.camel@dimi>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
Message-ID: <1121496640.22208.5.camel@localhost.localdomain>

On Sat, 2005-07-16 at 02:34 -0400, Dimi Paun wrote:
> On Fri, 2005-07-15 at 18:05 -0400, Jeff Spaleta wrote:
> > Prove to me that the complaints about the terminal represent a large
> > contingent of fedora's userbase.  I claim you and everyone else in
> > this thread represent a vocal minority of the fedora userbase as well
> > as the gnome userbase more generally. Prove me wrong.
> 
> Why not the other way: prove that there is a large number of people
> _complaining_ about that menu. All my experiences, without fail, has
> shown that menu to be highly enjoyed by all users: from completely
> clueless to advanced.

I just *love* clicking on that menu item.  It really makes my day.

Please, I know you miss the menu item, but do try to be at least
moderately realistic.
-- 
        Peter



From dimi at lattica.com  Sat Jul 16 07:13:15 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 16 Jul 2005 03:13:15 -0400
Subject: No more right click terminal
In-Reply-To: <1121496640.22208.5.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
Message-ID: <1121497995.11210.127.camel@dimi>

On Sat, 2005-07-16 at 02:50 -0400, Peter Jones wrote:
> > All my experiences, without fail, has
> > shown that menu to be highly enjoyed by all users: from completely
> > clueless to advanced.
> 
> Please, I know you miss the menu item, but do try to be at least
> moderately realistic.

It's not that I miss it that much -- I can maybe see some of the
arguments against it. I've got into this thread initially because
I felt people were told to take a hike.

Now, as for the "moderately realistic", you probably refer to my
statement that "completely clueless" users enjoyed it. 

I wasn't kidding. I've installed FC3 on my g/f box. She is a _very_
non-technical user by any conceivable measure. However, she needed
access to a terminal day one, and now she always has one opened.

I understand the "this is a bug" idea (to a certain point), but  
reality is harsh. It's going to take many years for this to change, 
and removing a generally useful feature way before its time is not
helpful.

Please do not misunderstand me: I think the removal is a mistake,
but I don't think it's a huge deal. I wouldn't have maybe even
posted at all in this thread if it was for the barrage of comments
like "go tell someone who cares", "take a hike, you're not our user",
etc. 

I think this defeats the very reason for having Fedora in the first
place (if I understood Michael Tieman correctly at FUDConf). And it
pains me to see this happen because I love Fedora. I really do.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From pjones at redhat.com  Sat Jul 16 07:45:41 2005
From: pjones at redhat.com (Peter Jones)
Date: Sat, 16 Jul 2005 03:45:41 -0400
Subject: No more right click terminal
In-Reply-To: <1121497995.11210.127.camel@dimi>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
Message-ID: <1121499941.22208.9.camel@localhost.localdomain>

On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:
> On Sat, 2005-07-16 at 02:50 -0400, Peter Jones wrote:
> > > All my experiences, without fail, has
> > > shown that menu to be highly enjoyed by all users: from completely
> > > clueless to advanced.
> > 
> > Please, I know you miss the menu item, but do try to be at least
> > moderately realistic.
> 
> It's not that I miss it that much -- I can maybe see some of the
> arguments against it. I've got into this thread initially because
> I felt people were told to take a hike.
> 
> Now, as for the "moderately realistic", you probably refer to my
> statement that "completely clueless" users enjoyed it. 

No, not that completely clueless users enjoyed it -- rather that it was
"highly enjoyed by" anybody at all.  I think this the sort of hyperbole
that, especially combined with the filling of mailboxes for days on end,
makes people ignore everything else you say completely.

-- 
        Peter



From bart.vanbrabant at zoeloelip.be  Sat Jul 16 08:36:11 2005
From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant)
Date: Sat, 16 Jul 2005 10:36:11 +0200
Subject: Bootup delays
In-Reply-To: <20050716041039.GB5755@nostromo.devel.redhat.com>
References: <42D838EC.1060402@zoeloelip.be>
	<20050716041039.GB5755@nostromo.devel.redhat.com>
Message-ID: <42D8C6FB.9040506@zoeloelip.be>

Bill Nottingham wrote:

>Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: 
>  
>
>>>From kernel 1432 and 1433 in rawhide my boot process has some serious
>>delays where my system doesn't seem to do anything and doesn't respond.
>>This also happens when logining in and starting gnome.
>>I made a bootchart from the 1426 kernel which runs fine and one form
>>1433 which suffers from those delays.
>>http://files.zoeloelip.be/1426.png
>>http://files.zoeloelip.be/1433.png
>>    
>>
>
>Looks like there's a 30 second process of just insmod, unless it's grouping
>them. If you could track down what driver is being silly, that could
>help a lot.
>
>Bill
>
>  
>
Is there an easy way to do this? Or just trying? Maybe you see some
drivers that has changed which causes this problem, here's me lsmod output:
Module                  Size  Used by
parport_pc             28933  1
lp                     13001  0
parport                40713  2 parport_pc,lp
sunrpc                170756  1
powernow_k8            15945  0
dm_mod                 58077  0
video                  15941  0
button                  6609  0
battery                 9413  0
asus_acpi              11093  0
ac                      4805  0
wacom                  13505  0
ipv6                  268033  10
ohci1394               41353  0
ieee1394              305209  1 ohci1394
yenta_socket           22989  0
rsrc_nonstatic         13249  1 yenta_socket
pcmcia_core            42857  2 yenta_socket,rsrc_nonstatic
ohci_hcd               26721  0
ehci_hcd               40653  0
i2c_nforce2             7233  0
i2c_core               21185  1 i2c_nforce2
snd_intel8x0m          18821  0
shpchp                 94277  0
snd_intel8x0           34817  1
snd_ac97_codec         79165  2 snd_intel8x0m,snd_intel8x0
snd_seq_dummy           3653  0
snd_seq_oss            37057  0
snd_seq_midi_event      8256  1 snd_seq_oss
snd_seq                62289  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          8781  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            51313  0
snd_mixer_oss          17857  1 snd_pcm_oss
snd_pcm                99017  4
snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pc m_oss
snd_timer              33605  2 snd_seq,snd_pcm
snd                    56901  12
snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_s
eq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore              10913  1 snd
snd_page_alloc         10313  3 snd_intel8x0m,snd_intel8x0,snd_pcm
sk98lin               176801  0
skge                   38737  0
joydev                  9601  0
xfs                   592241  2
exportfs                8897  1 xfs
sata_nv                 9669  0
libata                 47817  1 sata_nv
sd_mod                 20929  0
scsi_mod              147369  2 libata,sd_mod

Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/eda173be/attachment.sig>

From buildsys at redhat.com  Sat Jul 16 11:18:24 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 16 Jul 2005 07:18:24 -0400
Subject: rawhide report: 20050716 changes
Message-ID: <200507161118.j6GBIOcO021269@porkchop.devel.redhat.com>

 

 
Updated Packages:

GConf2-2.11.1-1
---------------
* Fri Jul 15 2005 Matthias Clasen <mclasen at redhat.com> 2.11.1-1
- Newer upstream version
- Drop upstreamed patch

OpenIPMI-1.4.14-5
-----------------
* Fri Jul 15 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-5
- Fixed missing change to not autostart in the initscript

* Wed Jul 06 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-4
- Made the initscript a replacing configfile

* Mon Jul 04 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-3
- Updated versions of the initscripts and sysconf files
- Fixed typo in preun script and changelog

ant-0:1.6.2-3jpp_11fc
---------------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> 0:1.6.2-3jpp_11fc
- Bootstrap onto ia64, ppc64, s390 and s390x.

* Wed Jun 15 2005 Gary Benson <gbenson at redhat.com> 0:1.6.2-3jpp_10fc
- Add the bsf subpackage since we now ship bsf.
- Remove gcj workaround (not correct, so assume not necessary).
- Remove jarfiles from the tarball.

* Mon Jun 06 2005 Gary Benson <gbenson at redhat.com>
- Make the javah task fall back to executing javah if
  com.sun.tools.javah.Main cannot be found.

aspell-12:0.60.3-2
------------------
* Fri Jul 15 2005 Ivana Varekova <varekova at redhat.com> 12:0.60.3-2
- fix install-info problem

* Wed Jul 13 2005 Ivana Varekova <varekova at redhat.com> 12:0.60.3-1
- update to 0.60.3 - (bug 141968) thanks to Dawid Gajownik 
- add BuildRequires: ncurses-devel, gettext 
- add config script patch (thanks tmraz at redhat.com)

* Mon Mar 07 2005 Ivana Varekova <varekova at redhat.com> 12:0.50.5-6
- rebuilt

aspell-af-50:0.50-4
-------------------
* Fri Jul 15 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.1-4
- rebuilt with aspell-0.60.3
aspell-bg-50:0.50-11
--------------------
* Fri Jul 15 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-11
- fix aspell dependence

aspell-br-50:0.50-4
-------------------
* Fri Jul 15 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.2-4
- build with aspell-0.60.3
aspell-ca-50:0.50-4
-------------------
* Fri Jul 15 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.2-4
- build with aspell-0.60.3
control-center-1:2.11.6-1
-------------------------
* Fri Jul 15 2005 Matthias Clasen <mclasen at redhat.com> - 1:2.11.6-1
- New upstream version

eclipse-bugzilla-1:0.1.1_fc-3
-----------------------------
* Fri Jul 15 2005 Andrew Overholt <overholt at redhat.com> 0.1.1_fc-3
- Use gbenson's new aot-compile-rpm.

eclipse-changelog-1:2.0.1_fc-22
-------------------------------
* Thu Jul 14 2005 Andrew Overholt <overholt at redhat.com> 2.0.1_fc-22
- Make use of new aot-compile-rpm.
- Bump appropriate requirements.
- Add patches to fix what output format should be (.tar.gz).

eclipse-pydev-1:0.9.3_fc-10
---------------------------
* Fri Jul 15 2005 Andrew Overholt <overholt at redhat.com> 0.9.3_fc-10
- Use gbenson's new aot-compile-rpm.

* Fri Jul 08 2005 Jeff Pound <jpound at redhat.com> 0.9.3_fc-9
- Fix eclipse build specification to be arch independant.
- Fix build.properties javacDebugInfo flag (Robin Green bz#161534)
- Add -g compile option (Robin Green bz#161534)

ethereal-0.10.11-4
------------------
* Fri Jul 15 2005 Radek Vokal <rvokal at redhat.com> 0.10.11-4
- fixed buildrequres (#163244)

gjdoc-0.7.5-4
-------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> 0.7.5-4
- Also build on ia64, ppc64, s390 and s390x.

* Tue Jul 05 2005 Andrew Overholt <overholt at redhat.com> 0.7.5-3
- Bump release for FC4 update.
- Downgrade gcc requirements to those present in FC4.

glib2-2.7.3-1
-------------
* Fri Jul 15 2005 Matthias Clasen <mclasen at redhat.com> - 2.7.3-1
- Update to 2.7.3

gnome-netstatus-2.11.1-1
------------------------
* Fri Jul 15 2005 Matthias Clasen <mclasen at redhat.com> - 2.11.1-1
- Newer upstream version

gnu-crypto-0:2.0.1-1jpp_7fc
---------------------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> - 0:2.0.1-1jpp_7fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

gthumb-2.6.6-1
--------------
* Fri Jul 15 2005 Matthias Clasen <mclasen at redhat.com> - 2.6.6-1
- Newer upstream version

jakarta-commons-logging-0:1.0.4-2jpp_6fc
----------------------------------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> - 0:1.0.4-2jpp_6fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

jsch-0:0.1.18-1jpp_2fc
----------------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> 0.1.18-1jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

k3b-0:0.12.2-1
--------------
* Thu Jul 14 2005 Harald Hoyer <harald at redhat.com> 0:0.12.2-1
- version 0.12.2
- ported some patches

* Mon Jul 11 2005 Harald Hoyer <harald at redhat.com> 0:0.11.23-2
- added "dvd+rw-tools cdrdao" to Requires

kernel-2.6.12-1.1434_FC5
------------------------
* Fri Jul 15 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git2

minicom-2.1-1
-------------
* Thu Jul 14 2005 Martin Stransky <stransky at redhat.com> 2.1-1
- New upstream version

mozilla-37:1.7.8-6
------------------
* Fri Jul 15 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.8-6
- Teach mozilla-nss.pc about system NSPR

* Fri Jul 15 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.8-5
- Fix a crash on 64bit platforms (#160330)

* Thu Jul 14 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.8-4
- mozilla-nss should also depend on the system nspr package now

nspr-4.6-4
----------
* Fri Jul 15 2005 Christopher Aillon <caillon at redhat.com> 4.6-4
- Use the NSPR version numbering scheme reported by NSPR,
  which unfortunately is not exactly the same as the real
  version (4.6 != 4.6.0 according to RPM and pkgconfig).

* Fri Jul 15 2005 Christopher Aillon <caillon at redhat.com> 4.6-3
- Correct the CFLAGS reported by pkgconfig

pup-0.0.2-1
-----------

pyxf86config-0.3.19-6
---------------------
* Fri Jul 15 2005 Paul Nasrat <pnasrat at redhat.com> - 0.3.19-6
- ExcludeArch ppc64 again

* Fri Jul 15 2005 Paul Nasrat <pnasrat at redhat.com> - 0.3.19-5
- Drop ppc64 ExcludeArch
- pyc and pyo includes

regexp-0:1.3-2jpp_3fc
---------------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> 0:1.3-2jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

spamassassin-3.1.0-0.pre4.fc5
-----------------------------
* Fri Jul 15 2005 Warren Togami <wtogami at redhat.com> - 3.1.0-0.pre4
- 3.1.0-pre4

squid-7:2.5.STABLE10-2
----------------------
* Fri Jul 15 2005 Martin Stransky <stransky at redhat.com> 7:2.5.STABLE10-2
- pam_auth and ncsa_auth have setuid (#162660)

system-config-bind-4.0.0-18_FC5
-------------------------------
* Fri Jul 15 2005 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-18_FC4
- fix bug 163304: handle empty contents in Zone.out
- fix bug 161988: create links to .mo files for bindconf
- fix bug 161987: don't use substring of translated string in DNSsec TrustedKeys
- fix bug 159534: add descriptions to deprecated record types
- fix bug 158441: shorten NamedConfOptions description strings

thunderbird-0:1.0.2-8
---------------------
* Fri Jul 15 2005 Christopher Aillon <caillon at redhat.com> 1.0.2-8
- Use system NSPR
- Fix crash on 64bit platforms (#160330)

tzdata-2005k-2
--------------
* Fri Jul 15 2005 Jakub Jelinek <jakub at redhat.com> 2005k-2
- 2005k
  - leap seconds update

uucp-1.07-11
------------
* Fri Jul 15 2005 Peter Vrabec <pvrabec at redhat.com> 1.07-11
- use -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE together with RPM_OPT_FLAGS

Broken deps for i386
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.i386 requires libpcap.so.0.8.3
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.2-7.i386 requires libpcap.so.0.8.3
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-regexp
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-bcel
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	isdn4k-utils - 3.2-29.ppc requires libpcap.so.0.8.3
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-regexp
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-bcel
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.2-7.ppc requires libpcap.so.0.8.3
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	rgmanager - 1.9.31-3.ia64 requires ccs
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	ppp - 2.4.2-7.ia64 requires libpcap.so.0.8.3()(64bit)
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	isdn4k-utils - 3.2-29.ia64 requires libpcap.so.0.8.3()(64bit)
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)



Broken deps for s390x
----------------------------------------------------------
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	ppp - 2.4.2-7.s390x requires libpcap.so.0.8.3()(64bit)
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-bcel
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-regexp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.x86_64 requires libpcap.so.0.8.3()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	ppp - 2.4.2-7.x86_64 requires libpcap.so.0.8.3()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	ppp - 2.4.2-7.s390 requires libpcap.so.0.8.3
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for ppc64
----------------------------------------------------------
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	ppp - 2.4.2-7.ppc64 requires libpcap.so.0.8.3()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	isdn4k-utils - 3.2-29.ppc64 requires libpcap.so.0.8.3()(64bit)
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis





From mattdm at mattdm.org  Sat Jul 16 12:58:19 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 16 Jul 2005 08:58:19 -0400
Subject: ANN: anaconda yum migration testing
In-Reply-To: <1121488882.11796.6.camel@enki.eridu>
References: <1121488882.11796.6.camel@enki.eridu>
Message-ID: <20050716125819.GA3783@jadzia.bu.edu>

On Sat, Jul 16, 2005 at 12:41:22AM -0400, Paul Nasrat wrote:
> Later in the week http/ftp installs will move to using yum as a back
> end. Some work in install speed optimisation will be needed but at the
> moment we are focussed on getting it working without.

Is there a mechanism for pointing at multiple repositories? Or am I gettin'
ahead of the game here? :)

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.



From walters at redhat.com  Sat Jul 16 15:07:05 2005
From: walters at redhat.com (Colin Walters)
Date: Sat, 16 Jul 2005 11:07:05 -0400
Subject: No more right click terminal
In-Reply-To: <20050716013240.GC16250@srv01.cluenet.de>
References: <Pine.LNX.4.44.0507151835060.17917-100000@linux>
	<1121473136.4036.70.camel@nexus.verbum.private>
	<20050716013240.GC16250@srv01.cluenet.de>
Message-ID: <1121526425.4036.97.camel@nexus.verbum.private>

On Sat, 2005-07-16 at 03:32 +0200, Daniel Roesen wrote:
> On Fri, Jul 15, 2005 at 08:18:56PM -0400, Colin Walters wrote:
> > No one's advocating removing the commandline, it is definitely useful
> > for the people developing the applications.
> 
> Then how about moving gnome-terminal, xterm etc. to Extras? As you say,
> if you have to use the shell it's a bug.

I didn't say that.  I said that if non-developers/non-sysadmins have to
use the terminal, it is a bug. 

I use gnome-terminal constantly every day, because I am a software
developer.

>  And you also say Fedora isn't
> aimed at "power users / developers" (however that is defined).

Fedora is clearly aimed at developers.  I think we should be spending a
lot of time supporting them.  But Fedora is also our idea of what a
general purpose OS should be.  And our default desktop reflects that
general purpose.  

One argument you could make is that we should include
nautilus-open-terminal in Core, and install it when you do a "Technical
Workstation" or whatever that install is called.  I doubt you'd find
many objections to that.

>  So
> logical consequence is that it shouldn't get installed by default,

I don't think that's a logical consequence; personally I don't think
it'd be unreasonable for it not to be installed by default when you do a
Personal Desktop install, but I'm not in charge of the menus.

>  and
> move to Extras.

That definitely doesn't make much sense.

> And if USERS feel the urge to use the command line, they should file
> bugzilla bugs. A no wait, they should go to... uhm... whomever they
> think that should provide a colorful mousable alternative to whatever
> they just wanted to to efficiently with a shell.

Nope...not at all what I said.

I do hope that Fedora users who also have programming skills will
understand that not all users can accomplish "everyday" tasks like
wireless network configuration with a terminal, and help out with our
goal to write programs or fix bugs in existing ones to make stuff work.




From walters at redhat.com  Sat Jul 16 15:12:08 2005
From: walters at redhat.com (Colin Walters)
Date: Sat, 16 Jul 2005 11:12:08 -0400
Subject: No more right click terminal
In-Reply-To: <1121497995.11210.127.camel@dimi>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
Message-ID: <1121526729.4036.102.camel@nexus.verbum.private>

On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:

> I wasn't kidding. I've installed FC3 on my g/f box. She is a _very_
> non-technical user by any conceivable measure. However, she needed
> access to a terminal day one, and now she always has one opened.

Why did she need a terminal?

> I understand the "this is a bug" idea (to a certain point), but  
> reality is harsh. It's going to take many years for this to change, 

Hopefully not many years.

> and removing a generally useful feature way before its time is not
> helpful.

The terminal is still available.  From half of the responses on this
thread you'd think it'd been removed entirely.

> Please do not misunderstand me: I think the removal is a mistake,
> but I don't think it's a huge deal. I wouldn't have maybe even
> posted at all in this thread if it was for the barrage of comments
> like "go tell someone who cares", "take a hike, you're not our user",
> etc. 

That's not at all what most of the responses were; see for example:
https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00308.html



From rms at 1407.org  Sat Jul 16 16:07:36 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Sat, 16 Jul 2005 17:07:36 +0100
Subject: No more right click terminal
In-Reply-To: <1121526729.4036.102.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
Message-ID: <1121530056.2773.4.camel@roque>

On Sat, 2005-07-16 at 11:12 -0400, Colin Walters wrote:
> > I understand the "this is a bug" idea (to a certain point), but  
> > reality is harsh. It's going to take many years for this to change, 
> 
> Hopefully not many years.

s/not//

Which world did you come from? Windows? MacOS? It looks like that each
time you say such an absurd statement.

The terminal is _the_ killer feature of an UNIX like operating system.

All the rest are bonuses. We're merely at the point where the GUI
bonuses clearly start overcoming those (some may say they are the only
one) of Windows and MacOS.

At the same time, the other mainstream OS's are bringing the terminal
back in (Apple's already done, Microsoft is on the verge of doing it,
since DOS doesn't really count).

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/3debdedc/attachment.sig>

From dimi at lattica.com  Sat Jul 16 16:15:28 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 16 Jul 2005 12:15:28 -0400
Subject: No more right click terminal
In-Reply-To: <1121526729.4036.102.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
Message-ID: <1121530528.11210.163.camel@dimi>

On Sat, 2005-07-16 at 11:12 -0400, Colin Walters wrote:
> On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:
> 
> > I wasn't kidding. I've installed FC3 on my g/f box. She is a _very_
> > non-technical user by any conceivable measure. However, she needed
> > access to a terminal day one, and now she always has one opened.
> 
> Why did she need a terminal?

OK, IIRC it was mainly:
  -- access to yum update/install
  -- access to scp

The scp one is tough to replace, because he needs to copy files back
and forth from my box. I can't see an easy way out from this one.
And to be honest, now she uses (by her own will BTW despite my
suggestion to use gedit) vim to edit files in a Terminal.

(On a side note, I don't blame her: gedit takes 2s to load on my
3GHz/1GB box, and when it starts it has the silly tab that takes
up vertical real-estate even if I only have a single file opened. 
She has a 500MHz box, much slower so it's a much longer wait :().

> That's not at all what most of the responses were; see for example:
> https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00308.html

For sure not most. And there was nothing even special about this thread,
but rather it was more "the straw that broke the camel's back".

The thread turned into a useful conversation even if it became partly a
bit of a flame fest lately. Kudos to the Red Hat folks who managed to
bring this back to rationality.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From alan at redhat.com  Sat Jul 16 16:20:19 2005
From: alan at redhat.com (Alan Cox)
Date: Sat, 16 Jul 2005 12:20:19 -0400
Subject: No more right click terminal
In-Reply-To: <20050715235546.GB1014250@hiwaay.net>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
	<42D84A57.2050604@bluga.net> <20050715235546.GB1014250@hiwaay.net>
Message-ID: <20050716162019.GK7345@devserv.devel.redhat.com>

On Fri, Jul 15, 2005 at 06:55:46PM -0500, Chris Adams wrote:
> > They also said we should remove the content menu to get to the terminal 
> > cause it scares people like my mom.
> 
> Can anyone cite a single case of this?

No but I can cite the reverse. Commodore made the mistake with the Amiga and
had to backpedal in the next release. They were however hiding the terminal
entirely not moving it off the default menu

Alan



From johnp at redhat.com  Sat Jul 16 16:28:36 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Sat, 16 Jul 2005 12:28:36 -0400
Subject: No more right click terminal
In-Reply-To: <1121530056.2773.4.camel@roque>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530056.2773.4.camel@roque>
Message-ID: <1121531316.21813.29.camel@localhost.localdomain>

On Sat, 2005-07-16 at 17:07 +0100, Rui Miguel Seabra wrote:
> On Sat, 2005-07-16 at 11:12 -0400, Colin Walters wrote:
> > > I understand the "this is a bug" idea (to a certain point), but  
> > > reality is harsh. It's going to take many years for this to change, 
> > 
> > Hopefully not many years.
> 
> s/not//
> 
> Which world did you come from? Windows? MacOS? It looks like that each
> time you say such an absurd statement.
> 
> The terminal is _the_ killer feature of an UNIX like operating system.
> 
> All the rest are bonuses. We're merely at the point where the GUI
> bonuses clearly start overcoming those (some may say they are the only
> one) of Windows and MacOS.
> 
> At the same time, the other mainstream OS's are bringing the terminal
> back in (Apple's already done, Microsoft is on the verge of doing it,
> since DOS doesn't really count).
> 
> Rui
> 

*sigh* I was hoping not to get sucked in but I feel the need to respond.
Does any of these systems have a right click open terminal button?  No.
In fact MacOS X's terminal is buried deep in the file system hierarchy.
If I am not mistaken we still have the terminal in the menus which you
can drag and drop to your desktop and panel.  And there is a plugin to
add the right click back.  It is not taking it away by any stretch of
the imagination.

But here is what it is taking away - the self defeating mentality that
the command line is needed on a desktop system.  I've seen so many bugs
ignored over the years because the answer on some forum would be, "that
is easy to fix, just open a terminal and type foo..."  No that is not
easy for everyone and if you are not sysadmin or developer no where
should you ever find the need to drop down to a terminal.  The former
group should know how to open up a terminal and make it convenient for
themselves to do so.  If normal people feel that they need the terminal
for some function then it is a bug we need to fix in the GUI.

Are we completely there yet? No. That is why we still have a terminal.
Do we need to promote the need for a terminal by including it in the
right click menu?  No. Reducing the right click menu to a few items is a
good idea.  Allowing extensions to be installed to tailor the right
click menu to a user's need is a good idea also.  I suspect those who
need the terminal in FC5 will be smart enough to find it.

-- 
John (J5) Palmieri <johnp at redhat.com>



From rms at 1407.org  Sat Jul 16 16:31:53 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Sat, 16 Jul 2005 17:31:53 +0100
Subject: No more right click terminal
In-Reply-To: <1121530528.11210.163.camel@dimi>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
Message-ID: <1121531513.2773.9.camel@roque>

On Sat, 2005-07-16 at 12:15 -0400, Dimi Paun wrote:
> The scp one is tough to replace, because he needs to copy files back
> and forth from my box.

Not really. It was very easy to make some users access
ssh://user at remotehost:, also thanks to the $HOME == Desktop, which
allowed them to automate many tasks they had to do on the servers, using
the GUI to transfer files. And What You See on the desktop Is What You
Get on the terminal too. Coherence plays a lot!

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/8daf3524/attachment.sig>

From johnp at redhat.com  Sat Jul 16 16:33:12 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Sat, 16 Jul 2005 12:33:12 -0400
Subject: No more right click terminal
In-Reply-To: <1121530528.11210.163.camel@dimi>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
Message-ID: <1121531592.21813.34.camel@localhost.localdomain>

On Sat, 2005-07-16 at 12:15 -0400, Dimi Paun wrote:
> On Sat, 2005-07-16 at 11:12 -0400, Colin Walters wrote:
> > On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:
> > 
> > > I wasn't kidding. I've installed FC3 on my g/f box. She is a _very_
> > > non-technical user by any conceivable measure. However, she needed
> > > access to a terminal day one, and now she always has one opened.
> > 
> > Why did she need a terminal?
> 
> OK, IIRC it was mainly:
>   -- access to yum update/install

Pup handles updates now and there are plans to add installing.

>   -- access to scp

You can use Nautilus to do scp. Go to places/add a server.., add a ssh
server, type in the details and now you have drag and drop
functionality.

If she really needs fast access to the terminal go in the menus and drag
the icon to the desktop or a panel.

-- 
John (J5) Palmieri <johnp at redhat.com>



From rms at 1407.org  Sat Jul 16 16:34:47 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Sat, 16 Jul 2005 17:34:47 +0100
Subject: No more right click terminal
In-Reply-To: <1121531316.21813.29.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530056.2773.4.camel@roque>
	<1121531316.21813.29.camel@localhost.localdomain>
Message-ID: <1121531687.2773.13.camel@roque>

On Sat, 2005-07-16 at 12:28 -0400, John (J5) Palmieri wrote:
> *sigh* I was hoping not to get sucked in but I feel the need to respond.
> Does any of these systems have a right click open terminal button?  No.

Yes, thank you for helping me make my point. Only who comes from those
systems really shuns a command line. Because in the case Windows it
_always_ sucked, and in the case of MacOS, only since X...

> But here is what it is taking away - the self defeating mentality that
> the command line is needed on a desktop system.

Thinking it has no use for other than a sysadmin or developer is a
defeating mentality. You just gave up on teaching less technical users a
very powerful tool.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/7801bc3b/attachment.sig>

From gmaxwell at gmail.com  Sat Jul 16 16:42:01 2005
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sat, 16 Jul 2005 12:42:01 -0400
Subject: No more right click terminal
In-Reply-To: <20050716162019.GK7345@devserv.devel.redhat.com>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
	<42D84A57.2050604@bluga.net> <20050715235546.GB1014250@hiwaay.net>
	<20050716162019.GK7345@devserv.devel.redhat.com>
Message-ID: <e692861c05071609426c63f8ea@mail.gmail.com>

On 7/16/05, Alan Cox <alan at redhat.com> wrote:
> On Fri, Jul 15, 2005 at 06:55:46PM -0500, Chris Adams wrote:
> > > They also said we should remove the content menu to get to the terminal
> > > cause it scares people like my mom.
> >
> > Can anyone cite a single case of this?
> 
> No but I can cite the reverse. Commodore made the mistake with the Amiga and
> had to backpedal in the next release. They were however hiding the terminal
> entirely not moving it off the default menu

I'm not sure why there is so much fuss about this.

I agree that it was a mistake to reduce the accessibility of the
terminal, and I know a lot of non-geek users that get a lot of use out
of it...  at the same time, this change is completely consistent with
the overall trend in Gnome development:  It follows naturally from
the, in my view mistaken, assumption that the best way to make the
system easier to use is to design it for an operator with
substantially diminished mental capacity rather than just designing
for people who don't want to become Unix sysadmins just to use their
computers.

If you disagree with moving the terminal then you most likely disagree
with hundreds of other things Gnome has done in the name of
usability... So, you should be arguing these individual issues on the
Gnome list or you should be lobbying for the transition of Fedora Core
to another default desktop environment.

It is unreasonable to ask the distribution maintainers to turn back
the tide of gnome development, with patches, a teaspoon at a time.



From rnicholsNOSPAM at comcast.net  Sat Jul 16 16:58:49 2005
From: rnicholsNOSPAM at comcast.net (Robert Nichols)
Date: Sat, 16 Jul 2005 11:58:49 -0500
Subject: No more right click terminal
In-Reply-To: <1121531316.21813.29.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com>
	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<604aa79105071515053d280939@mail.gmail.com>	<1121495640.11210.107.camel@dimi>	<1121496640.22208.5.camel@localhost.localdomain>	<1121497995.11210.127.camel@dimi>	<1121526729.4036.102.camel@nexus.verbum.private>	<1121530056.2773.4.camel@roque>
	<1121531316.21813.29.camel@localhost.localdomain>
Message-ID: <dbbec9$m1l$1@sea.gmane.org>

John (J5) Palmieri wrote:
>  If normal people feel that they need the terminal
> for some function then it is a bug we need to fix in the GUI.
> 
> Are we completely there yet? No. That is why we still have a terminal.
> Do we need to promote the need for a terminal by including it in the
> right click menu?  No. Reducing the right click menu to a few items is a
> good idea.  

Oh, yes.  Having quick access to the tool to change the background image
is just _so_ much more important to _so_ many people than is quick
access to a terminal when you run into something that is inconvenient to
handle in whatever GUI tool you happen to be running at the time.

Look at it this way.  If you occasionally need access to a terminal and
starting one isn't quick and easy, then you'll probably decide you need
to keep a terminal window running all the time.  Which is dirtier:
having a "Create Terminal" entry in a convenient menu, or keeping a
mostly unneeded (not for me, BTW) terminal process running "just in
case".



From walters at redhat.com  Sat Jul 16 17:26:32 2005
From: walters at redhat.com (Colin Walters)
Date: Sat, 16 Jul 2005 13:26:32 -0400
Subject: No more right click terminal
In-Reply-To: <1121530528.11210.163.camel@dimi>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
Message-ID: <1121534792.27612.12.camel@nexus.verbum.private>

On Sat, 2005-07-16 at 12:15 -0400, Dimi Paun wrote:

> The scp one is tough to replace, because he needs to copy files back
> and forth from my box. I can't see an easy way out from this one.

Ah, but you see we GNOME hackers have been putting a lot of effort into
making our applications support gnome-vfs which can handle ssh/sftp.

As John pointed out, it's as easy as "Places->Connect to Server"; and
once you've done that you can access it from applications like GEdit.

But not only that - even better for many cases is gnome-user-share:

http://cvs.gnome.org/viewcvs/gnome-user-share/

Here's some RPM links:
http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.i386.rpm
http://people.redhat.com/alexl/RPMS/gnome-user-share-0.2-1.src.rpm

We really need to get this into Extras.

All you do is drop files you want accessible publicly into your ~/Public
folder, and everyone else on the local area network can see them when
you go to "Computer->Network".  No need to know about IP addresses, ssh,
servers, etc.  Now if you're not on the same local network it won't
work, but if you are it can replace ssh/sftp/ftp in a much much better
way.




From rms at 1407.org  Sat Jul 16 17:38:44 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Sat, 16 Jul 2005 18:38:44 +0100
Subject: nautilus-open-terminal proposed to Extras by me [Was: Re: No more
	right click terminal]
In-Reply-To: <1121531687.2773.13.camel@roque>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530056.2773.4.camel@roque>
	<1121531316.21813.29.camel@localhost.localdomain>
	<1121531687.2773.13.camel@roque>
Message-ID: <1121535524.2773.28.camel@roque>

Hello,

For those who, like me, care about this issue and have the power to help
me solve it, I submitted a package to Extras.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/22be3a6f/attachment.sig>

From Axel.Thimm at ATrpms.net  Sat Jul 16 18:11:01 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 16 Jul 2005 20:11:01 +0200
Subject: ANN: anaconda yum migration testing
In-Reply-To: <20050716125819.GA3783@jadzia.bu.edu>
References: <1121488882.11796.6.camel@enki.eridu>
	<20050716125819.GA3783@jadzia.bu.edu>
Message-ID: <20050716181101.GA8258@neu.nirvana>

On Sat, Jul 16, 2005 at 08:58:19AM -0400, Matthew Miller wrote:
> On Sat, Jul 16, 2005 at 12:41:22AM -0400, Paul Nasrat wrote:
> > Later in the week http/ftp installs will move to using yum as a back
> > end. Some work in install speed optimisation will be needed but at the
> > moment we are focussed on getting it working without.
> 
> Is there a mechanism for pointing at multiple repositories? Or am I gettin'
> ahead of the game here? :)

And looking even further in the cristal ball, after anaconda will be
upgrading-while-installing and 3rd-party repo extensible, how will
this fit with anaconda in RHEL? Would the external repo support make
it there, too?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/bd852593/attachment.sig>

From jkeating at j2solutions.net  Sun Jul 17 02:41:04 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 16 Jul 2005 19:41:04 -0700
Subject: No more right click terminal
In-Reply-To: <1121534792.27612.12.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
Message-ID: <1121568064.3273.2.camel@localhost.localdomain>

On Sat, 2005-07-16 at 13:26 -0400, Colin Walters wrote:
> All you do is drop files you want accessible publicly into your ~/Public
> folder, and everyone else on the local area network can see them when
> you go to "Computer->Network".  No need to know about IP addresses, ssh,
> servers, etc.  Now if you're not on the same local network it won't
> work, but if you are it can replace ssh/sftp/ftp in a much much better
> way.
> 

Er, what protocol does this use to share?  What authentication methods
are there?  What ports does it use?  Why would there suddenly be a
publicly viewable folder WITHIN MY HOME DIR?!

I strongly object this EVER making it into core without some
administrative method of restricting access or the ability to 'turn it
off'.  Heck, I'd rather not see it there period.  User workstations are
not for sharing files.  A file server is designed and useful for that.
The sysadmin in my shudders w/ terror.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/ee36b3a9/attachment.sig>

From stickster at gmail.com  Sat Jul 16 21:13:34 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Sat, 16 Jul 2005 17:13:34 -0400
Subject: nautilus-open-terminal proposed to Extras by me [Was: Re: No
	more right click terminal]
In-Reply-To: <1121535524.2773.28.camel@roque>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530056.2773.4.camel@roque>
	<1121531316.21813.29.camel@localhost.localdomain>
	<1121531687.2773.13.camel@roque>  <1121535524.2773.28.camel@roque>
Message-ID: <1121548414.3027.7.camel@localhost.localdomain>

On Sat, 2005-07-16 at 18:38 +0100, Rui Miguel Seabra wrote:
> Hello,
> 
> For those who, like me, care about this issue and have the power to help
> me solve it, I submitted a package to Extras.

Just so other readers here who aren't subbed to fedora-extras-list know
that other people care as well --    :-)

http://www.redhat.com/archives/fedora-extras-list/2005-July/msg00896.html

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050716/d9d3c0dd/attachment.sig>

From ben.steeves at gmail.com  Sat Jul 16 23:05:01 2005
From: ben.steeves at gmail.com (Ben Steeves)
Date: Sat, 16 Jul 2005 20:05:01 -0300
Subject: No more right click terminal
In-Reply-To: <1121568064.3273.2.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
Message-ID: <7ebb24d1050716160560b9fb2a@mail.gmail.com>

On 7/16/05, Jesse Keating <jkeating at j2solutions.net> wrote:
> On Sat, 2005-07-16 at 13:26 -0400, Colin Walters wrote:
> > All you do is drop files you want accessible publicly into your ~/Public
> > folder, and everyone else on the local area network can see them when
> > you go to "Computer->Network".  No need to know about IP addresses, ssh,
> > servers, etc.  Now if you're not on the same local network it won't
> > work, but if you are it can replace ssh/sftp/ftp in a much much better
> > way.
> >
> 
> I strongly object this EVER making it into core without some
> administrative method of restricting access or the ability to 'turn it
> off'.

Well, as Colin mentioned, it's not even in Extras yet let alone Core,
and "turning it off" is as easy as not installing it or "yum remove
gnome-user-share" if it's already installed (I highly doubt something
like this -- if it ever made it into Core (which I doubt) -- would
ever be installed and turned on by default, right Colin?)

> User workstations are
> not for sharing files.  A file server is designed and useful for that.
> The sysadmin in my shudders w/ terror.

Sure, in a corporate environment with a file server, this is probably
not something you'd want to deploy (but then again, maybe you would,
we scp things back and forth all the time at work...), but in a 2- or
3- machine home environment, this might be just the ticket.

-- 
Ben Steeves                     _                    bcs at metacon.ca
 The ASCII ribbon campaign     ( )            ben.steeves at gmail.com
   against HTML e-mail          X                GPG ID: 0xB3EBF1D9
http://www.metacon.ca/bcs      / \     Yahoo Messenger: ben_steeves



From ianburrell at gmail.com  Sun Jul 17 00:50:22 2005
From: ianburrell at gmail.com (Ian Burrell)
Date: Sat, 16 Jul 2005 17:50:22 -0700
Subject: No more right click terminal
In-Reply-To: <dbbec9$m1l$1@sea.gmane.org>
References: <42D5743A.6010300@shahms.com>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530056.2773.4.camel@roque>
	<1121531316.21813.29.camel@localhost.localdomain>
	<dbbec9$m1l$1@sea.gmane.org>
Message-ID: <d91f09cd0507161750253396eb@mail.gmail.com>

On 7/16/05, Robert Nichols <rnicholsNOSPAM at comcast.net> wrote:
> 
> Oh, yes.  Having quick access to the tool to change the background image
> is just _so_ much more important to _so_ many people than is quick
> access to a terminal when you run into something that is inconvenient to
> handle in whatever GUI tool you happen to be running at the time.
> 
> Look at it this way.  If you occasionally need access to a terminal and
> starting one isn't quick and easy, then you'll probably decide you need
> to keep a terminal window running all the time.  Which is dirtier:
> having a "Create Terminal" entry in a convenient menu, or keeping a
> mostly unneeded (not for me, BTW) terminal process running "just in
> case".
> 

There are other ways to open a terminal other than that menu item. 
Before this discussion, I didn't even know that 'Open Terminal'
existed there.  I have used Gnome for ages.

The Terminal is in the start menu with all the other applications.  
It is a little hard to figure out where it lives.  I never can
remember that it is in System Tools.

There are also other fast ways to open a terminal.  It is easy to make
a launcher on the panel.  The second thing I do with a new install is
make a terminal launcher.  This is the proper way to do things.  The
launcher is in the same place with all the applications that people
like to use frequently.

I think it would quite reasonable to argue for a terminal launcher in
the default panel.  This is something which is easy for Fedora to
change.  And something which Fedora already customizes.

 - Ian



From vonbrand at inf.utfsm.cl  Sun Jul 17 00:17:02 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sat, 16 Jul 2005 20:17:02 -0400
Subject: No more right click terminal 
In-Reply-To: Your message of "Fri, 15 Jul 2005 19:20:24 +0200."
	<20050715172024.GG19895@chrys.ms.mff.cuni.cz> 
Message-ID: <200507170017.j6H0H2a3021922@laptop11.inf.utfsm.cl>

Miloslav Trmac <mitr at volny.cz> wrote:

[...]

> No, it is not.  Most packages have a single maintainer; there are
> two maintainers for OO.o, four (?) maintainers for X.Org X11; only
> the kernel has a dedicated (and much larger) "kernel team".

I'd think it is more in the line that most maintainers care for /multiple/
packages, and only some of the very large/basic things get exlusive
attention.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From vonbrand at inf.utfsm.cl  Sun Jul 17 00:32:22 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sat, 16 Jul 2005 20:32:22 -0400
Subject: List purpose (was Re: No more right click terminal) 
In-Reply-To: Your message of "Fri, 15 Jul 2005 18:10:37 +0200."
	<20050715161037.GE10161@srv01.cluenet.de> 
Message-ID: <200507170032.j6H0WMRv022087@laptop11.inf.utfsm.cl>

Daniel Roesen <dr at cluenet.de> wrote:

[...]

> I won't waste hours on writing a patch that gets just ignored.

Too bad for you that that is /exactly/ what fuels open source... many
people proposing patches, very few getting ever included is what gave you
the system you are currently enjoying.

Humm... just go out and find out what all what you get here would cost you
in propietary stuff. See you get it in exchange for exactly the kind of
work you are complaining about, check how many hours of "wasted patch
writing" you owe Fedora, and come back when you've paid up.

>                                                                I don't
> have this surplus time. My only chance to influence things is to bring
> up my arguments.

Ever heard the phrase "Code talks, bullshit walks"?

>                  All else gets decided by Red Hat or "upstream" anyway
> (and "upstream" can be overridden by Red Hat again if they like... if
> RED HAT likes, not the community).

And Red Hat can be overridden by the community, or just abandoned for
something else. Your point being?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From vonbrand at inf.utfsm.cl  Sun Jul 17 00:11:19 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sat, 16 Jul 2005 20:11:19 -0400
Subject: No more right click terminal 
In-Reply-To: Your message of "Fri, 15 Jul 2005 16:03:54 +0200."
	<20050715140354.GB10161@srv01.cluenet.de> 
Message-ID: <200507170011.j6H0BJxb021851@laptop11.inf.utfsm.cl>

Daniel Roesen <dr at cluenet.de> wrote:
> On Thu, Jul 14, 2005 at 08:36:50AM -0400, Dimi Paun wrote:
> > On Thu, 2005-07-14 at 08:11 -0400, Jeff Spaleta wrote:
> > > Debating the worth of any particular study,
> > > here.. is pointless..
> > 
> > Very smart. It seems that _anything_ is pointless to discuss here.

> Indeed. It's still all "what Red Hat likes", and screw the rest. At
> least that's my (oh, not really only mine) impression.

Can't speak for the rest here, please.

> Just look at what random stuff is thrown into core by Red Hat folks,
> whereas outsiders with really useful additions are sent off to Extras.

Could you be more specific? Just whining about "junk in core" and "useful
stuff left out" doesn't help a bit.

[...]

> The "we follow upstream!" mantra is also only followed when it's
> fitting.

Again, please be specific.

>          If the Fedora heads like a change, it gets done (see all the
> custom patches that regularily pop up in packages),

Fixing real bugs and/or patches that are pending upstream, as far as I have
seen up to here.

>                                                     and if outsiders
> request changes that Fedora heads don't like, we'll hear a "shut up and
> go upstream, we follow upstream, basta".

If you don't like it, fork ahead. Nobody is forcing you to use vanilla
Fedora, is there?

[...]

> The terminal launch option now disappearing completely out of immediate
> reach is a major blow, once again. I really wonder where this is
> heading. The last really usable desktop for me was GNOME/Enlightenment
> in RH 6.2 (and 7.x, but I had that only at work place and dunno how much
> effort the IT folks there had put into making it work). Later on, things
> got dumbed down more and more. Now we are at metacity (I call it
> mediocracy) and people still keep on removing features etc. I wonder
> when will install twm or fvwm again as "powerful, feature-rich"
> replacement for the hello_world that metacity is. Sigh.

You can try KDE, or XFCE. Or go for outsider window managers.

[...]

> Don't get me wrong. I cannot complain - it all comes for free, I greatly
> respect that and am grateful for the chance to run an OS which mostly
> fits my needs for zarro bucks and the source comes with it too so I can
> fiddle with it if I REALLY need to. It just sucks to always here the
> fairy tale of the "community" distro Fedora is supposed to be, and all
> I can see is quite the contrary (except of course if it comes to offload
> the boring stuff like maintaining older releases [Fedora Legacy],
> betatesting new random stuff put into Core etc.).

Sorry, I don't understand you at all. You'd have to be much more specific
and constructive with your criticism, or you will just be *PLONK*ed left
and right.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From sundaram at redhat.com  Sun Jul 17 03:04:16 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 17 Jul 2005 08:34:16 +0530
Subject: system-config-sshd ?
In-Reply-To: <42D7ED99.8050506@flashmail.com>
References: <42D7ED99.8050506@flashmail.com>
Message-ID: <42D9CAB0.2060901@redhat.com>

Arthur Pemberton wrote:

> Hello,
>
> I have been a Fedora user since FC1, and now I'd like to contribute to
> the project. I know some Python, but no GUI (as yet). My more tested
> programming skills lie is pascal and delphi. I am interested in building
> a cnfiguration tool for sshd to help me learn the python language
> better, and also to contribute to the fedora project. But I need some 
> help:
>
> Knowledge - HOWTOs, tutorial, whitepapers, etc that I need to read to
> properly write a system-config applicat ion
> Rules - Standards,  and guidelines that I shoudl follow
> Technologies - gui toolkits, modules, etc that I should stick to in
> learning and building a system-config tool.
>
cvs.fedora.redhat.com and system-config* srpms has all the code 
necessary to give you an idea on how these tools work. That would a good 
starting point. It would be nice if you can explain what you have 
planned for system-config-sshd.

regards
Rahul



From bernie at develer.com  Sun Jul 17 03:39:33 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Sun, 17 Jul 2005 05:39:33 +0200
Subject: Avoiding cups on clients
Message-ID: <42D9D2F5.1070208@develer.com>

Hello,

in our office setup, the only available printer is
shared by a server running cups.

Is seems that clients still need to run cupsd just
to print through this printer.  cupsd takes a few
seconds to start and is generally a resource hog.

Is it possible to access the remote printer without
using a local cupsd?  If not, how could I turn off
unneeded cups components such as the web server at
port 632 and local printer discovery?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From dalive at flashmail.com  Sun Jul 17 03:57:37 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Sat, 16 Jul 2005 23:57:37 -0400
Subject: system-config-sshd ?
In-Reply-To: <42D9CAB0.2060901@redhat.com>
References: <42D7ED99.8050506@flashmail.com> <42D9CAB0.2060901@redhat.com>
Message-ID: <42D9D731.8020703@flashmail.com>

Rahul Sundaram wrote:

> Arthur Pemberton wrote:
>
>> Hello,
>>
>> I have been a Fedora user since FC1, and now I'd like to contribute to
>> the project. I know some Python, but no GUI (as yet). My more tested
>> programming skills lie is pascal and delphi. I am interested in building
>> a cnfiguration tool for sshd to help me learn the python language
>> better, and also to contribute to the fedora project. But I need some 
>> help:
>>
>> Knowledge - HOWTOs, tutorial, whitepapers, etc that I need to read to
>> properly write a system-config applicat ion
>> Rules - Standards,  and guidelines that I shoudl follow
>> Technologies - gui toolkits, modules, etc that I should stick to in
>> learning and building a system-config tool.
>>
> cvs.fedora.redhat.com and system-config* srpms has all the code 
> necessary to give you an idea on how these tools work. That would a 
> good starting point. It would be nice if you can explain what you have 
> planned for system-config-sshd.
>
> regards
> Rahul
>
Thanks for at least replying. I was beginning to ponder whether my mail 
had actually reached the other list members.

Well my understanding is that the system-config tools are written in 
python and use the gtk toolkit. As much as I wanted my frst gui app to 
be in Qt, since GTK+ is the quasi standard, I have no problem in that.

My idea thus far is to build a dictionary of objects from the 
sshd_config each object would represet a configuration option (some what 
simplified explanation).

I have invisioned the UI as a basic tab oriented design, with the 
following tabs:

ACCESS CONTROL
AUTHENTICATIONSECURITY
TCP/IP
X SERVER
GENERAL

Of course I would use the best widgets based on the type of data the 
config option is expecting (boolean, string, file path, single option 
list, multipel option list, sequential integers, time). So far it looks 
like a majority of the config options can be satisfied with a checkbox. 
I'm also considering defining a class for each of the afforementioned 
data types.

I also hope to make each option's object hold a property called 
'description' which would store the explainations given at 
http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config or at least a 
link to view it from a less memory consuming location (maybe an xml file).

Program would also do backups of config file for the sake of regression.

Thats what I have in mind for now.

Feel free to comment and suggest critically.

BTW: forgive my ignorance, but I only know how to get binary packages 
with yum, how can I use yum to get src rpms? Or must I download them the 
old fashion way?



From dalive at flashmail.com  Sun Jul 17 03:58:55 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Sat, 16 Jul 2005 23:58:55 -0400
Subject: Avoiding cups on clients
In-Reply-To: <42D9D2F5.1070208@develer.com>
References: <42D9D2F5.1070208@develer.com>
Message-ID: <42D9D77F.4080501@flashmail.com>

Bernardo Innocenti wrote:

>Hello,
>
>in our office setup, the only available printer is
>shared by a server running cups.
>
>Is seems that clients still need to run cupsd just
>to print through this printer.  cupsd takes a few
>seconds to start and is generally a resource hog.
>
>Is it possible to access the remote printer without
>using a local cupsd?  If not, how could I turn off
>unneeded cups components such as the web server at
>port 632 and local printer discovery?
>
>  
>
Not to deter you, but this post is best suited for 
fedora-list at redhat.com. The topic of this mailing list is strictly that 
of development of Fedora.



From sundaram at redhat.com  Sun Jul 17 04:10:02 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 17 Jul 2005 09:40:02 +0530
Subject: system-config-sshd ?
In-Reply-To: <42D9D731.8020703@flashmail.com>
References: <42D7ED99.8050506@flashmail.com> <42D9CAB0.2060901@redhat.com>
	<42D9D731.8020703@flashmail.com>
Message-ID: <42D9DA1A.1050500@redhat.com>

Arthur Pemberton wrote:

> Rahul Sundaram wrote:
>
>> Arthur Pemberton wrote:
>>
>>> Hello,
>>>
>>> I have been a Fedora user since FC1, and now I'd like to contribute to
>>> the project. I know some Python, but no GUI (as yet). My more tested
>>> programming skills lie is pascal and delphi. I am interested in 
>>> building
>>> a cnfiguration tool for sshd to help me learn the python language
>>> better, and also to contribute to the fedora project. But I need 
>>> some help:
>>>
>>> Knowledge - HOWTOs, tutorial, whitepapers, etc that I need to read to
>>> properly write a system-config applicat ion
>>> Rules - Standards,  and guidelines that I shoudl follow
>>> Technologies - gui toolkits, modules, etc that I should stick to in
>>> learning and building a system-config tool.
>>>
>> cvs.fedora.redhat.com and system-config* srpms has all the code 
>> necessary to give you an idea on how these tools work. That would a 
>> good starting point. It would be nice if you can explain what you 
>> have planned for system-config-sshd.
>>
>> regards
>> Rahul
>>
> Thanks for at least replying. I was beginning to ponder whether my 
> mail had actually reached the other list members.

Well there is a lot of traffic lately and your mail was getting lost in 
the static

>
> Well my understanding is that the system-config tools are written in 
> python and use the gtk toolkit. As much as I wanted my frst gui app to 
> be in Qt, since GTK+ is the quasi standard, I have no problem in that.
>
> My idea thus far is to build a dictionary of objects from the 
> sshd_config each object would represet a configuration option (some 
> what simplified explanation).
>
> I have invisioned the UI as a basic tab oriented design, with the 
> following tabs:
>
> ACCESS CONTROL
> AUTHENTICATIONSECURITY
> TCP/IP
> X SERVER
> GENERAL
>
> Of course I would use the best widgets based on the type of data the 
> config option is expecting (boolean, string, file path, single option 
> list, multipel option list, sequential integers, time). So far it 
> looks like a majority of the config options can be satisfied with a 
> checkbox. I'm also considering defining a class for each of the 
> afforementioned data types.
>
> I also hope to make each option's object hold a property called 
> 'description' which would store the explainations given at 
> http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config or at least a 
> link to view it from a less memory consuming location (maybe an xml 
> file).
>
> Program would also do backups of config file for the sake of regression.
>
> Thats what I have in mind for now.
>
> Feel free to comment and suggest critically.
>
Other system configuration tools are more suited to do the basic 
functionality and not expose a lot of details. You could do it in a more 
comprehensive way but the UI should be designed to do the basic things 
in an easy way first

> BTW: forgive my ignorance, but I only know how to get binary packages 
> with yum, how can I use yum to get src rpms? Or must I download them 
> the old fashion way?

yum install yum-utils and use yumdownloader. Other utils in there like 
yum-builddep is useful for this purpose too

regards
Rahul



From dalive at flashmail.com  Sun Jul 17 04:31:01 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Sun, 17 Jul 2005 00:31:01 -0400
Subject: system-config-sshd ?
In-Reply-To: <42D9DA1A.1050500@redhat.com>
References: <42D7ED99.8050506@flashmail.com>
	<42D9CAB0.2060901@redhat.com>	<42D9D731.8020703@flashmail.com>
	<42D9DA1A.1050500@redhat.com>
Message-ID: <42D9DF05.6010007@flashmail.com>

Rahul Sundaram wrote:

> Arthur Pemberton wrote:
>
>> Rahul Sundaram wrote:
>>
>>> Arthur Pemberton wrote:
>>>
>>>> Hello,
>>>>
>>>> I have been a Fedora user since FC1, and now I'd like to contribute to
>>>> the project. I know some Python, but no GUI (as yet). My more tested
>>>> programming skills lie is pascal and delphi. I am interested in 
>>>> building
>>>> a cnfiguration tool for sshd to help me learn the python language
>>>> better, and also to contribute to the fedora project. But I need 
>>>> some help:
>>>>
>>>> Knowledge - HOWTOs, tutorial, whitepapers, etc that I need to read to
>>>> properly write a system-config applicat ion
>>>> Rules - Standards,  and guidelines that I shoudl follow
>>>> Technologies - gui toolkits, modules, etc that I should stick to in
>>>> learning and building a system-config tool.
>>>>
>>> cvs.fedora.redhat.com and system-config* srpms has all the code 
>>> necessary to give you an idea on how these tools work. That would a 
>>> good starting point. It would be nice if you can explain what you 
>>> have planned for system-config-sshd.
>>>
>>> regards
>>> Rahul
>>>
>> Thanks for at least replying. I was beginning to ponder whether my 
>> mail had actually reached the other list members.
>
>
> Well there is a lot of traffic lately and your mail was getting lost 
> in the static
>
>>
>> Well my understanding is that the system-config tools are written in 
>> python and use the gtk toolkit. As much as I wanted my frst gui app 
>> to be in Qt, since GTK+ is the quasi standard, I have no problem in 
>> that.
>>
>> My idea thus far is to build a dictionary of objects from the 
>> sshd_config each object would represet a configuration option (some 
>> what simplified explanation).
>>
>> I have invisioned the UI as a basic tab oriented design, with the 
>> following tabs:
>>
>> ACCESS CONTROL
>> AUTHENTICATIONSECURITY
>> TCP/IP
>> X SERVER
>> GENERAL
>>
>> Of course I would use the best widgets based on the type of data the 
>> config option is expecting (boolean, string, file path, single option 
>> list, multipel option list, sequential integers, time). So far it 
>> looks like a majority of the config options can be satisfied with a 
>> checkbox. I'm also considering defining a class for each of the 
>> afforementioned data types.
>>
>> I also hope to make each option's object hold a property called 
>> 'description' which would store the explainations given at 
>> http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config or at least 
>> a link to view it from a less memory consuming location (maybe an xml 
>> file).
>>
>> Program would also do backups of config file for the sake of regression.
>>
>> Thats what I have in mind for now.
>>
>> Feel free to comment and suggest critically.
>>
> Other system configuration tools are more suited to do the basic 
> functionality and not expose a lot of details. You could do it in a 
> more comprehensive way but the UI should be designed to do the basic 
> things in an easy way first

Care to present me with some easily observed examples so that I could 
better apply what you're suggesting to my problem?

>
>> BTW: forgive my ignorance, but I only know how to get binary packages 
>> with yum, how can I use yum to get src rpms? Or must I download them 
>> the old fashion way?
>
>
> yum install yum-utils and use yumdownloader. Other utils in there like 
> yum-builddep is useful for this purpose too
>
> regards
> Rahul
>



From sundaram at redhat.com  Sun Jul 17 04:34:52 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 17 Jul 2005 10:04:52 +0530
Subject: system-config-sshd ?
In-Reply-To: <42D9DF05.6010007@flashmail.com>
References: <42D7ED99.8050506@flashmail.com>	<42D9CAB0.2060901@redhat.com>	<42D9D731.8020703@flashmail.com>	<42D9DA1A.1050500@redhat.com>
	<42D9DF05.6010007@flashmail.com>
Message-ID: <42D9DFEC.50407@redhat.com>

Hi

>>>
>> Other system configuration tools are more suited to do the basic 
>> functionality and not expose a lot of details. You could do it in a 
>> more comprehensive way but the UI should be designed to do the basic 
>> things in an easy way first
>
>
> Care to present me with some easily observed examples so that I could 
> better apply what you're suggesting to my problem? 

Sure.  system-config-httpd only exposes basic functionality for example. 
GUI applications shouldnt be designed with the aim to expose all the 
configuration options but as task based systems. Figuring out what 
options fit into which task group would be a good idea. Try create some 
mockups using glade. 

regards
Rahul



From dimi at lattica.com  Sun Jul 17 04:49:42 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 17 Jul 2005 00:49:42 -0400
Subject: No more right click terminal
In-Reply-To: <1121534792.27612.12.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
Message-ID: <1121575782.11210.169.camel@dimi>

On Sat, 2005-07-16 at 13:26 -0400, Colin Walters wrote:
> All you do is drop files you want accessible publicly into your
> ~/Public
> folder, and everyone else on the local area network can see them when
> you go to "Computer->Network".  No need to know about IP addresses,
> ssh, servers, etc.  Now if you're not on the same local network it
> won't work, but if you are it can replace ssh/sftp/ftp in a much much
> better way.

This is really nice. We need a way to allow people to easily share
files, it is a useful and necessary tool sometimes (even in a formal
banking environment where for a bunch of reasons I needed it).

My particular use case is on a different network, but I'll try to
look at the Places | Connect to Server... It seems like a cool
feature.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dalive at flashmail.com  Sun Jul 17 05:02:00 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Sun, 17 Jul 2005 01:02:00 -0400
Subject: system-config-sshd ?
In-Reply-To: <42D9DFEC.50407@redhat.com>
References: <42D7ED99.8050506@flashmail.com>	<42D9CAB0.2060901@redhat.com>	<42D9D731.8020703@flashmail.com>	<42D9DA1A.1050500@redhat.com>	<42D9DF05.6010007@flashmail.com>
	<42D9DFEC.50407@redhat.com>
Message-ID: <42D9E648.20302@flashmail.com>

Rahul Sundaram wrote:

> Hi
>
>>>>
>>> Other system configuration tools are more suited to do the basic 
>>> functionality and not expose a lot of details. You could do it in a 
>>> more comprehensive way but the UI should be designed to do the basic 
>>> things in an easy way first
>>
>>
>>
>> Care to present me with some easily observed examples so that I could 
>> better apply what you're suggesting to my problem? 
>
>
> Sure.  system-config-httpd only exposes basic functionality for 
> example. GUI applications shouldnt be designed with the aim to expose 
> all the configuration options but as task based systems. Figuring out 
> what options fit into which task group would be a good idea. Try 
> create some mockups using glade.
> regards
> Rahul
>
Will do.



From symbiont at berlios.de  Sun Jul 17 08:18:11 2005
From: symbiont at berlios.de (Jeff Pitman)
Date: Sun, 17 Jul 2005 16:18:11 +0800
Subject: NetworkManager
In-Reply-To: <1121430552.10494.3.camel@nexus.verbum.private>
References: <1121343762.11210.84.camel@dimi>
	<200507151519.59773.symbiont@berlios.de>
	<1121430552.10494.3.camel@nexus.verbum.private>
Message-ID: <200507171618.11913.symbiont@berlios.de>

On Friday 15 July 2005 20:29, Colin Walters wrote:
> On Fri, 2005-07-15 at 15:19 +0800, Jeff Pitman wrote:
> > If this type of setup was added to NM, it would be very, very nice.
>
> That type of usage is one of the major reasons why we chose to use
> bind for NetworkManager. ?I'm not sure if NetworkManager's VPN
> support takes advantage of it yet, but it could if it doesn't.

If not, you might want to make note the order in which bind comes up and 
whether the availablility of that particular DNS is available at the 
time.  Bind will blacklist forwarders if they're not available at the 
time of a resolve.  Even if it's up later and good to go.  You have to 
restart bind to get it to resolve against these servers.

Just FYI for any future enhancements that are built around this...

-- 
-jeff



From arnaud.abelard at univ-nantes.fr  Sun Jul 17 09:18:16 2005
From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=)
Date: Sun, 17 Jul 2005 11:18:16 +0200
Subject: ANN: anaconda yum migration testing
In-Reply-To: <1121488882.11796.6.camel@enki.eridu>
References: <1121488882.11796.6.camel@enki.eridu>
Message-ID: <42DA2258.9000405@univ-nantes.fr>

Paul Nasrat wrote:
> Over the next week as part of the work to try get anaconda installs
> using yum I'm going to switch over to yum by default:
> 
> * nfs installs will use yum as a back end
> * nfsiso installs will not be available
> 
> Other install methods will fall back on the old method of
> depsolving/installing
> 
> Later in the week http/ftp installs will move to using yum as a back
> end. Some work in install speed optimisation will be needed but at the
> moment we are focussed on getting it working without.

One of my wishes about this project would be to be able to give the url 
of a remote (nfs, http, ftp) file (a yum.conf-like file) to easily 
specify a list of repository...

> 
> Paul 
> 

AA.



From buildsys at redhat.com  Sun Jul 17 11:09:50 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 17 Jul 2005 07:09:50 -0400
Subject: rawhide report: 20050717 changes
Message-ID: <200507171109.j6HB9oGP026933@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.x86_64 requires libpcap.so.0.8.3()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.2-7.x86_64 requires libpcap.so.0.8.3()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-bcel
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-regexp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)



Broken deps for i386
----------------------------------------------------------
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-regexp
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-bcel
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.i386 requires libpcap.so.0.8.3
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	ppp - 2.4.2-7.i386 requires libpcap.so.0.8.3
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	ppp - 2.4.2-7.s390x requires libpcap.so.0.8.3()(64bit)
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)



Broken deps for ppc
----------------------------------------------------------
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-regexp
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-bcel
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.ppc requires libpcap.so.0.8.3
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	ppp - 2.4.2-7.ppc requires libpcap.so.0.8.3



Broken deps for ia64
----------------------------------------------------------
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	isdn4k-utils - 3.2-29.ia64 requires libpcap.so.0.8.3()(64bit)
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	rgmanager - 1.9.31-3.ia64 requires ccs
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	ppp - 2.4.2-7.ia64 requires libpcap.so.0.8.3()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3



Broken deps for ppc64
----------------------------------------------------------
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	isdn4k-utils - 3.2-29.ppc64 requires libpcap.so.0.8.3()(64bit)
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	ppp - 2.4.2-7.ppc64 requires libpcap.so.0.8.3()(64bit)
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	firstboot - 1.3.43-1.noarch requires system-config-display
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	ppp - 2.4.2-7.s390 requires libpcap.so.0.8.3
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis





From sundaram at redhat.com  Sun Jul 17 12:52:08 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 17 Jul 2005 18:22:08 +0530
Subject: nautilus-open-terminal proposed to Extras by me [Was: Re: No
 more	right click terminal]
In-Reply-To: <1121535524.2773.28.camel@roque>
References: <42D5743A.6010300@shahms.com>
	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<604aa79105071515053d280939@mail.gmail.com>	<1121495640.11210.107.camel@dimi>	<1121496640.22208.5.camel@localhost.localdomain>	<1121497995.11210.127.camel@dimi>	<1121526729.4036.102.camel@nexus.verbum.private>	<1121530056.2773.4.camel@roque>	<1121531316.21813.29.camel@localhost.localdomain>	<1121531687.2773.13.camel@roque>
	<1121535524.2773.28.camel@roque>
Message-ID: <42DA5478.1070207@redhat.com>

Rui Miguel Seabra wrote:

>Hello,
>
>For those who, like me, care about this issue and have the power to help
>me solve it, I submitted a package to Extras.
>
>Rui
>
>  
>
Great . A constructive thing to do

regards
Rahul



From walters at redhat.com  Sun Jul 17 15:36:43 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 11:36:43 -0400
Subject: No more right click terminal
In-Reply-To: <1121568064.3273.2.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
Message-ID: <1121614603.28161.17.camel@nexus.verbum.private>

On Sat, 2005-07-16 at 19:41 -0700, Jesse Keating wrote:
> On Sat, 2005-07-16 at 13:26 -0400, Colin Walters wrote:
> > All you do is drop files you want accessible publicly into your ~/Public
> > folder, and everyone else on the local area network can see them when
> > you go to "Computer->Network".  No need to know about IP addresses, ssh,
> > servers, etc.  Now if you're not on the same local network it won't
> > work, but if you are it can replace ssh/sftp/ftp in a much much better
> > way.
> > 

Sigh...I'm amazed that people react so violently to something I think is
so obviously useful.  I'll answer your email in reverse order:

> I strongly object this EVER making it into core without some
> administrative method of restricting access or the ability to 'turn it
> off'.  

I believe startup is keyed off a GConf preference.  When we integrate it
into the upcoming GNOME session services framework the GConf-keying
should happen automatically.

> Heck, I'd rather not see it there period.  User workstations are
> not for sharing files.  A file server is designed and useful for that.
> The sysadmin in my shudders w/ terror.

Right, so next time I go to a coffee shop with a friend and want to
share files, we'll just haul along my enterprise file server...

Seriously, even at work at Red Hat's Westford office where we do have a
file server it's been really useful.  I don't use the file server
because the normal usage requires I have a NFS home directory, and NFS
sucks with laptops.  I want to be able to unplug my laptop and go.

It's significantly easier for me to drag and drop a patch into my
~/Public directory and tell my coworkers to find it on
"Computer->Network->walters' Files" than it is to scp it to the file
server, and have them (likely) scp it off.  

I might also note it's also more efficient in terms of network usage.

On to your technical questions:

> Er, what protocol does this use to share? 

HTTP; it runs Apache as your user.

>  What authentication methods
> are there? 

None, the idea is the files are public.

>  What ports does it use? 

It's dynamically bound and announced via Rendezvous. 

>  Why would there suddenly be a
> publicly viewable folder WITHIN MY HOME DIR?!

Isn't that what many installations of Apache have done for years with
~/public_html off your file server?





From walters at verbum.org  Sun Jul 17 16:54:44 2005
From: walters at verbum.org (Colin Walters)
Date: Sun, 17 Jul 2005 12:54:44 -0400
Subject: No more right click terminal
In-Reply-To: <e692861c05071609426c63f8ea@mail.gmail.com>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
	<42D84A57.2050604@bluga.net> <20050715235546.GB1014250@hiwaay.net>
	<20050716162019.GK7345@devserv.devel.redhat.com>
	<e692861c05071609426c63f8ea@mail.gmail.com>
Message-ID: <1121619285.28161.25.camel@nexus.verbum.private>

On Sat, 2005-07-16 at 12:42 -0400, Gregory Maxwell wrote:

> I agree that it was a mistake to reduce the accessibility of the
> terminal, and I know a lot of non-geek users that get a lot of use out
> of it...  at the same time, this change is completely consistent with
> the overall trend in Gnome development:  It follows naturally from
> the, in my view mistaken, assumption that the best way to make the
> system easier to use is to design it for an operator with
> substantially diminished mental capacity rather than just designing
> for people who don't want to become Unix sysadmins just to use their
> computers.

Not knowing how to use a terminal does not mean you have "substantially
diminished mental capacity".  

I have several mathematician friends who can run intellectual circles
around me in a number of areas (even besides math) like philosophy and
literature, but don't know or care how computers work.

The idea is to design the desktop for people who want to use the
computer to get work done (sending email, writing documents, etc), not
learn how it works.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/28be454a/attachment.sig>

From katzj at redhat.com  Sun Jul 17 17:21:50 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 17 Jul 2005 13:21:50 -0400
Subject: ANN: anaconda yum migration testing
In-Reply-To: <20050716125819.GA3783@jadzia.bu.edu>
References: <1121488882.11796.6.camel@enki.eridu>
	<20050716125819.GA3783@jadzia.bu.edu>
Message-ID: <1121620910.13479.1.camel@bree.local.net>

On Sat, 2005-07-16 at 08:58 -0400, Matthew Miller wrote:
> On Sat, Jul 16, 2005 at 12:41:22AM -0400, Paul Nasrat wrote:
> > Later in the week http/ftp installs will move to using yum as a back
> > end. Some work in install speed optimisation will be needed but at the
> > moment we are focussed on getting it working without.
> 
> Is there a mechanism for pointing at multiple repositories? Or am I gettin'
> ahead of the game here? :)

Just to reprise the reply I sent to anaconda-devel-list here as well...

Yeah, that's getting a tad ahead :-)  We need to get back to where
everything that has traditionally worked with anaconda works and then we
can start really looking at some of the multi-repo type things.  

Jeremy



From katzj at redhat.com  Sun Jul 17 17:22:58 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 17 Jul 2005 13:22:58 -0400
Subject: ANN: anaconda yum migration testing
In-Reply-To: <42DA2258.9000405@univ-nantes.fr>
References: <1121488882.11796.6.camel@enki.eridu>
	<42DA2258.9000405@univ-nantes.fr>
Message-ID: <1121620979.13479.2.camel@bree.local.net>

On Sun, 2005-07-17 at 11:18 +0200, Arnaud Ab?lard wrote:
> One of my wishes about this project would be to be able to give the url 
> of a remote (nfs, http, ftp) file (a yum.conf-like file) to easily 
> specify a list of repository...

The problem is that generic repositories don't necessarily have all of
the support needed for an installable tree, so giving a URL like this
wouldn't give all the information needed for doing an install.  

Jeremy



From jkeating at j2solutions.net  Sun Jul 17 17:55:03 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 10:55:03 -0700
Subject: No more right click terminal
In-Reply-To: <1121614603.28161.17.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
Message-ID: <1121622903.2769.25.camel@yoda.loki.me>

On Sun, 2005-07-17 at 11:36 -0400, Colin Walters wrote:
> Sigh...I'm amazed that people react so violently to something I think is
> so obviously useful.  I'll answer your email in reverse order:

Useful or not, I have never liked the idea of more file serving things I
have to hunt for and turn off.  In a corporate environment with
sensitive data I absolutely cannot have any file sharing system that is
unauthenticated.  Useful comes at a price, and most often that price is
lowered security.  Usability is most often a fine line struck between
ease of use and security of the system.  Some distros are much 'easier'
to use because they sacrifice security for usability.  Lindows (or
whatever it is now) is like that.  Every user is root so making changes
to the system is very 'easy' as well as sharing files w/ other users on
the system.  Of course, I hope any sane person shudders at the idea of
every user being root.  Thats like... XP Home.  Now I'm not comparing
Fedora to XP, I'm just hoping that you realize that usability comes at a
cost and when that cost is Security, extreme care must be taken to how
this usability is used and managed.

> > I strongly object this EVER making it into core without some
> > administrative method of restricting access or the ability to 'turn it
> > off'.  
> 
> I believe startup is keyed off a GConf preference.  When we integrate it
> into the upcoming GNOME session services framework the GConf-keying
> should happen automatically.

I'm afraid I lack the knowledge of GConf to understand this statement.
Do you mean that it will default to off?

> > Heck, I'd rather not see it there period.  User workstations are
> > not for sharing files.  A file server is designed and useful for that.
> > The sysadmin in my shudders w/ terror.
> 
> Right, so next time I go to a coffee shop with a friend and want to
> share files, we'll just haul along my enterprise file server...

My users would be fired if they opened up a unauthenticated share in a
coffee shop.  Scp, usb fob, https w/ authentication, something along
those lines.  Not everybody works in an environment where it is OK if
somebody outside the company gets a hold of source code that is being
worked on.

> Seriously, even at work at Red Hat's Westford office where we do have a
> file server it's been really useful.  I don't use the file server
> because the normal usage requires I have a NFS home directory, and NFS
> sucks with laptops.  I want to be able to unplug my laptop and go.

We don't use NFS home dirs for that reason as well.  We actually use
Samba is it allows for much better security and flexibility with file
ownership and quotas on the file server itself.  It becomes just an icon
on the desktop or another item in Computer to get to the file server.
There are public read/write directories (still requires an authenticated
user to the samba server to see them), read-only user directories and a
Private/ directory within user's directories that are viewable only by
that user.  It is very easy for a user to drag a file to the appropriate
folder and tell the other use to find it there.  Then it gets backed up
too, so that when the user drops their laptop and fags the disk, we have
a copy of their files.  They didn't just leave it in their home
directory because everybody could find it there, why put it anywhere
else?

> It's significantly easier for me to drag and drop a patch into my
> ~/Public directory and tell my coworkers to find it on
> "Computer->Network->walters' Files" than it is to scp it to the file
> server, and have them (likely) scp it off.  
>
> I might also note it's also more efficient in terms of network usage.

It is also easier and more network efficient for some folks to keep
using telnet to access remote systems.  This does not make it better or
desired in a large amount of areas.

> On to your technical questions:
> 
> > Er, what protocol does this use to share? 
> 
> HTTP; it runs Apache as your user.

What port then?  Will the system 'automatically' open this port on the
user configured firewall, because the system thinks that it should be
open (much like cups)?

> >  What authentication methods
> > are there? 
> 
> None, the idea is the files are public.
> 
> >  What ports does it use? 
> 
> It's dynamically bound and announced via Rendezvous. 

Ok, that answers my above question and scares the crap out of me.  I'll
ask again.  When dynamically bound will it take it upon itself to open
said port on the firewall?

> >  Why would there suddenly be a
> > publicly viewable folder WITHIN MY HOME DIR?!
> 
> Isn't that what many installations of Apache have done for years with
> ~/public_html off your file server?

This also required changing the default permissions on /home and
your /home/foo directory.  Very very bad juju there as well if it were a
shared system.

I guess bottom line is that this technology might be useful in some
environments.  However it poses a (IMHO severe) security risk in many
other environments and I'd like to see Fedora continue the train of
thought to turn off potentially security risky services by default and
make the user make a conscious decision to turn the service back on.  I
also hope that any UI designed to manage this service requires a root
password so that joe user couldn't override an administrative setting to
disable this service (especially if it fiddles w/ the firewall once
enabled).

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From johnp at redhat.com  Sun Jul 17 18:34:28 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Sun, 17 Jul 2005 14:34:28 -0400
Subject: No more right click terminal
In-Reply-To: <1121622903.2769.25.camel@yoda.loki.me>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
Message-ID: <1121625268.21813.63.camel@localhost.localdomain>

On Sun, 2005-07-17 at 10:55 -0700, Jesse Keating wrote:
> On Sun, 2005-07-17 at 11:36 -0400, Colin Walters wrote:
> > Sigh...I'm amazed that people react so violently to something I think is
> > so obviously useful.  I'll answer your email in reverse order:
> 
> Useful or not, I have never liked the idea of more file serving things I
> have to hunt for and turn off.  In a corporate environment with
> sensitive data I absolutely cannot have any file sharing system that is
> unauthenticated.  Useful comes at a price, and most often that price is
> lowered security.  

Usability and security are not mutually exclusive.  Yes there are some
points that they are diametrically opposed.  

> Usability is most often a fine line struck between
> ease of use and security of the system.  Some distros are much 'easier'
> to use because they sacrifice security for usability.  Lindows (or
> whatever it is now) is like that.  Every user is root so making changes
> to the system is very 'easy' as well as sharing files w/ other users on
> the system.  Of course, I hope any sane person shudders at the idea of
> every user being root.

Not to defend Linspire's track record but I don't think this is the case
anymore.

>   Thats like... XP Home.  Now I'm not comparing
> Fedora to XP, I'm just hoping that you realize that usability comes at a
> cost and when that cost is Security, extreme care must be taken to how
> this usability is used and managed.

Yes care needs to be taken and it is in the notion that the user share
would not be turned on by default and an admin could make it so a user
can not turn it on.

> > > I strongly object this EVER making it into core without some
> > > administrative method of restricting access or the ability to 'turn it
> > > off'.  
> > 
> > I believe startup is keyed off a GConf preference.  When we integrate it
> > into the upcoming GNOME session services framework the GConf-keying
> > should happen automatically.
> 
> I'm afraid I lack the knowledge of GConf to understand this statement.
> Do you mean that it will default to off?

As an admin of Fedora (I'm assuming you are one) you should get yourself
familiar with GConf.  It is basically a per user configuration database
that has key/value pair data in it.  Each key can be marked with a
default or mandatory value by the admin.  Defaults can be overrided by
the user, mandatory keys can not.  You would simply set the GConf key
for user-share startup to be mandatory false.  The cool thing about this
is you can use Sabayon http://www.gnome.org/projects/sabayon/ to do your
configuration without having to know much about GConf.  I assume you
test before you roll desktops out and like to keep the configuration
similar in such a highly secure environment.  Sabayon is an example of
usability increasing security.  I think you will appreciate it. 

> > > Heck, I'd rather not see it there period.  User workstations are
> > > not for sharing files.  A file server is designed and useful for that.
> > > The sysadmin in my shudders w/ terror.
> > 
> > Right, so next time I go to a coffee shop with a friend and want to
> > share files, we'll just haul along my enterprise file server...
> 
> My users would be fired if they opened up a unauthenticated share in a
> coffee shop.  Scp, usb fob, https w/ authentication, something along
> those lines.  Not everybody works in an environment where it is OK if
> somebody outside the company gets a hold of source code that is being
> worked on.

All valid points.

> > Seriously, even at work at Red Hat's Westford office where we do have a
> > file server it's been really useful.  I don't use the file server
> > because the normal usage requires I have a NFS home directory, and NFS
> > sucks with laptops.  I want to be able to unplug my laptop and go.
> 
> We don't use NFS home dirs for that reason as well.  We actually use
> Samba is it allows for much better security and flexibility with file
> ownership and quotas on the file server itself.  It becomes just an icon
> on the desktop or another item in Computer to get to the file server.
> There are public read/write directories (still requires an authenticated
> user to the samba server to see them), read-only user directories and a
> Private/ directory within user's directories that are viewable only by
> that user.  It is very easy for a user to drag a file to the appropriate
> folder and tell the other use to find it there.  Then it gets backed up
> too, so that when the user drops their laptop and fags the disk, we have
> a copy of their files.  They didn't just leave it in their home
> directory because everybody could find it there, why put it anywhere
> else?

But of course this is your environment and it works well for you.  It is
not everyones.  Another note is that having the Public/Private folder
still does not prevent a user from accidentally pushing a file to Public
that should have been private.  Same issue with the user-share.
Ultimately the user needs to be somewhat responsible.  We do try to
prevent them from shooting themselves in the foot but we can't be
foolproof.

> > On to your technical questions:
> > 
> > > Er, what protocol does this use to share? 
> > 
> > HTTP; it runs Apache as your user.
> 
> What port then?  Will the system 'automatically' open this port on the
> user configured firewall, because the system thinks that it should be
> open (much like cups)?

No.

> > >  What authentication methods
> > > are there? 
> > 
> > None, the idea is the files are public.
> > 
> > >  What ports does it use? 
> > 
> > It's dynamically bound and announced via Rendezvous. 
> 
> Ok, that answers my above question and scares the crap out of me.  I'll
> ask again.  When dynamically bound will it take it upon itself to open
> said port on the firewall?

No.

> > >  Why would there suddenly be a
> > > publicly viewable folder WITHIN MY HOME DIR?!
> > 
> > Isn't that what many installations of Apache have done for years with
> > ~/public_html off your file server?
> 
> This also required changing the default permissions on /home and
> your /home/foo directory.  Very very bad juju there as well if it were a
> shared system.
> 
> I guess bottom line is that this technology might be useful in some
> environments.  However it poses a (IMHO severe) security risk in many
> other environments and I'd like to see Fedora continue the train of
> thought to turn off potentially security risky services by default and
> make the user make a conscious decision to turn the service back on.  

We do this, no change there.  The user needs to turn it on.

> I
> also hope that any UI designed to manage this service requires a root
> password so that joe user couldn't override an administrative setting to
> disable this service (especially if it fiddles w/ the firewall once
> enabled).

Asking Joe user for root tends to be the wrong way to look at things.
If it is a managed environment then the sysadmin can make it so the user
can't turn it on and also not install the package.

-- 
John (J5) Palmieri <johnp at redhat.com>



From walters at redhat.com  Sun Jul 17 18:41:20 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 14:41:20 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121622903.2769.25.camel@yoda.loki.me>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
Message-ID: <1121625681.28161.85.camel@nexus.verbum.private>

On Sun, 2005-07-17 at 10:55 -0700, Jesse Keating wrote:
> On Sun, 2005-07-17 at 11:36 -0400, Colin Walters wrote:
> > Sigh...I'm amazed that people react so violently to something I think is
> > so obviously useful.  I'll answer your email in reverse order:
> 
> Useful or not, I have never liked the idea of more file serving things I
> have to hunt for and turn off.  In a corporate environment with
> sensitive data I absolutely cannot have any file sharing system that is
> unauthenticated.  

Sure, you can turn it off in that case.

Longer term though I don't think gnome-user-share is incompatible with
controlling information flow in a corporate environment.  For example,
with SELinux you could ensure that every file a software developer
creates is labeled with a type like developer_home_t or something.  Then
imagine that incoming WebDAV requests include the security context of
the invoking process on the remote machine.  gnome-user-share could then
do access checks versus that context.

So you as a system administrator could enforce in a *mandatory* way that
no person logged in as a marketing person (with type marketing_t) could
access files labeled as developer_home_t, even over the network.

With trusted computing you can even ensure that a marketing person can't
subvert the controls by loading a misconfigured or malicious OS that
would send the wrong security context.

Things do get more complicated if you want to allow some sharing between
marketing and development; the real point I'm trying to make is that
gnome-user-share is just a technology for sharing files and there's no
fundamental reason it couldn't be enhanced to work better in a managed
corporate environment as long as it doesn't cost the user experience of
the other use cases (friends in coffee shops, etc.).

> I'm afraid I lack the knowledge of GConf to understand this statement.
> Do you mean that it will default to off?

The default chosen is unrelated to the use of GConf technology; I think
if it was included in Fedora it would default to on.

> My users would be fired if they opened up a unauthenticated share in a
> coffee shop.  Scp, usb fob, https w/ authentication, something along
> those lines.  Not everybody works in an environment where it is OK if
> somebody outside the company gets a hold of source code that is being
> worked on.

This doesn't make much sense to me; it isn't gnome-user-share's fault if
a user drops a confidential document in ~/Public any more than it's
Evolution's fault if they email it to evilcracker at example.com.

If your users have their own laptops that they use for work, I would
expect to be able to use my own laptop to drop a picture in my ~/Public
to share with a friend at a coffee shop; I'd expect the company to trust
me not to do this with confidential data.

Now if your company owns the laptops you can do what you want, the
expectation being that users will not do non-work-related things with
their laptops.  But if you were to turn off gnome-user-share, in
parallel you should also configure Evolution to not allow sending email
to non-work addresses with attachments...

> What port then?  Will the system 'automatically' open this port on the
> user configured firewall, because the system thinks that it should be
> open (much like cups)?

I think it's incompatible with the firewall.  Personally I turned off
the firewall long ago; I don't think it provides much security really.
That's a whole other flamewar though =)

(let's please not go there now...)

> I guess bottom line is that this technology might be useful in some
> environments.  However it poses a (IMHO severe) security risk in many
> other environments and I'd like to see Fedora continue the train of
> thought to turn off potentially security risky services by default and
> make the user make a conscious decision to turn the service back on. 

I'd rather make Fedora a usable, general purpose desktop OS by default;
for managed corporate environments there are always going to be a lot of
tweaks to make; disabling gnome-user share (or changing its config)
would just be one more.

>  I
> also hope that any UI designed to manage this service requires a root
> password so that joe user couldn't override an administrative setting to
> disable this service (especially if it fiddles w/ the firewall once
> enabled).

Ugh!  You can tell GConf to have a 'mandatory' flag for a key so that
user applications aren't supposed to be able to change it (the idea is
in the UI it would be greyed out); but there's nothing (short of
SELinux) preventing a compromised or buggy application from ignoring the
flag and exec()ing gnome-user-share or whatever.

All of our desktop work is predicated on the idea that the user doesn't
know the root password.  You should never need that to get work done.




From sundaram at redhat.com  Sun Jul 17 18:49:37 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 00:19:37 +0530
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121625681.28161.85.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<604aa79105071515053d280939@mail.gmail.com>	<1121495640.11210.107.camel@dimi>	<1121496640.22208.5.camel@localhost.localdomain>	<1121497995.11210.127.camel@dimi>	<1121526729.4036.102.camel@nexus.verbum.private>	<1121530528.11210.163.camel@dimi>	<1121534792.27612.12.camel@nexus.verbum.private>	<1121568064.3273.2.camel@localhost.localdomain>	<1121614603.28161.17.camel@nexus.verbum.private>	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
Message-ID: <42DAA841.4090106@redhat.com>

Hi

>>I'm afraid I lack the knowledge of GConf to understand this statement.
>>Do you mean that it will default to off?
>>    
>>
>
>The default chosen is unrelated to the use of GConf technology; I think
>if it was included in Fedora it would default to on.
>
It should be providing strong hints to the user like a sharing icon 
emblem and things like that. Just so that its obvious most of the time

regards
Rahul



From walters at redhat.com  Sun Jul 17 18:55:12 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 14:55:12 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <42DAA841.4090106@redhat.com>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
Message-ID: <1121626512.28161.93.camel@nexus.verbum.private>

On Mon, 2005-07-18 at 00:19 +0530, Rahul Sundaram wrote:
> Hi
> 
> >>I'm afraid I lack the knowledge of GConf to understand this statement.
> >>Do you mean that it will default to off?
> >>    
> >>
> >
> >The default chosen is unrelated to the use of GConf technology; I think
> >if it was included in Fedora it would default to on.
> >
> It should be providing strong hints to the user like a sharing icon 
> emblem and things like that. Just so that its obvious most of the time

J5 walked over to my room and we chatted about this a bit; perhaps the
first time you drop a file in there it should show a warning dialog
saying that files in there are truly public.




From fedora at camperquake.de  Sun Jul 17 18:59:16 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 17 Jul 2005 20:59:16 +0200
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121626512.28161.93.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
Message-ID: <20050717205916.3721678f@nausicaa.camperquake.de>

Hi.

Colin Walters <walters at redhat.com> wrote:


> > >The default chosen is unrelated to the use of GConf technology; I
> > >think if it was included in Fedora it would default to on.

I do not think this is a really clever idea, but....

> J5 walked over to my room and we chatted about this a bit; perhaps the
> first time you drop a file in there it should show a warning dialog
> saying that files in there are truly public.

How about offering to enable it when a user drops a file in there?

-- 
"Staring is not a viable problem solving strategy."  -- Stanley Buzuka



From jkeating at j2solutions.net  Sun Jul 17 19:00:45 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 12:00:45 -0700
Subject: No more right click terminal
In-Reply-To: <1121625268.21813.63.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625268.21813.63.camel@localhost.localdomain>
Message-ID: <1121626845.2769.31.camel@yoda.loki.me>

On Sun, 2005-07-17 at 14:34 -0400, John (J5) Palmieri wrote:
> But of course this is your environment and it works well for you.  It is
> not everyones.  Another note is that having the Public/Private folder
> still does not prevent a user from accidentally pushing a file to Public
> that should have been private.  Same issue with the user-share.
> Ultimately the user needs to be somewhat responsible.  We do try to
> prevent them from shooting themselves in the foot but we can't be
> foolproof.
> 

But in our environment, you still have to be an authenticated user to
see stuff in the public space.  It's "public" to authenticated users.
No auth?  No view.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From walters at redhat.com  Sun Jul 17 19:05:32 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 15:05:32 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <20050717205916.3721678f@nausicaa.camperquake.de>
References: <42D5743A.6010300@shahms.com>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
	<20050717205916.3721678f@nausicaa.camperquake.de>
Message-ID: <1121627132.28161.97.camel@nexus.verbum.private>

On Sun, 2005-07-17 at 20:59 +0200, Ralf Ertzinger wrote:

> How about offering to enable it when a user drops a file in there?

Sure, that makes sense. It would keep everyone else from seeing a lot of
empty shares, too.

I just don't like the idea of a totally non-discoverable feature that
users have to dig through GConf or something to enable.




From sundaram at redhat.com  Sun Jul 17 19:05:57 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 00:35:57 +0530
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121626512.28161.93.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<604aa79105071515053d280939@mail.gmail.com>	<1121495640.11210.107.camel@dimi>	<1121496640.22208.5.camel@localhost.localdomain>	<1121497995.11210.127.camel@dimi>	<1121526729.4036.102.camel@nexus.verbum.private>	<1121530528.11210.163.camel@dimi>	<1121534792.27612.12.camel@nexus.verbum.private>	<1121568064.3273.2.camel@localhost.localdomain>	<1121614603.28161.17.camel@nexus.verbum.private>	<1121622903.2769.25.camel@yoda.loki.me>	<1121625681.28161.85.camel@nexus.verbum.private>	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
Message-ID: <42DAAC15.4060904@redhat.com>

Colin Walters wrote:

>On Mon, 2005-07-18 at 00:19 +0530, Rahul Sundaram wrote:
>  
>
>>Hi
>>
>>    
>>
>>>>I'm afraid I lack the knowledge of GConf to understand this statement.
>>>>Do you mean that it will default to off?
>>>>   
>>>>
>>>>        
>>>>
>>>The default chosen is unrelated to the use of GConf technology; I think
>>>if it was included in Fedora it would default to on.
>>>
>>>      
>>>
>>It should be providing strong hints to the user like a sharing icon 
>>emblem and things like that. Just so that its obvious most of the time
>>    
>>
>
>J5 walked over to my room and we chatted about this a bit; perhaps the
>first time you drop a file in there it should show a warning dialog
>saying that files in there are truly public.
>
>  
>
Auto enabling on demand with a dialog explaining it a short manner (help 
for more details) unless administrator restricts it seems to be a good 
thing to do too
regards
Rahul



From fedora at camperquake.de  Sun Jul 17 19:10:04 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 17 Jul 2005 21:10:04 +0200
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121627132.28161.97.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
	<20050717205916.3721678f@nausicaa.camperquake.de>
	<1121627132.28161.97.camel@nexus.verbum.private>
Message-ID: <20050717211004.6049aef8@nausicaa.camperquake.de>

Hi.

Colin Walters <walters at redhat.com> wrote:

> Sure, that makes sense. It would keep everyone else from seeing a lot of
> empty shares, too.

An option to "Enable just for this session" would be nice, too.

-- 
Anthropomorphism is stalking the streets.



From jkeating at j2solutions.net  Sun Jul 17 19:15:21 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 12:15:21 -0700
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121625681.28161.85.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
Message-ID: <1121627721.2769.44.camel@yoda.loki.me>

On Sun, 2005-07-17 at 14:41 -0400, Colin Walters wrote:
> Longer term though I don't think gnome-user-share is incompatible with
> controlling information flow in a corporate environment.  For example,
> with SELinux you could ensure that every file a software developer
> creates is labeled with a type like developer_home_t or something.  Then
> imagine that incoming WebDAV requests include the security context of
> the invoking process on the remote machine.  gnome-user-share could then
> do access checks versus that context.
> 
> So you as a system administrator could enforce in a *mandatory* way that
> no person logged in as a marketing person (with type marketing_t) could
> access files labeled as developer_home_t, even over the network.
> 
> With trusted computing you can even ensure that a marketing person can't
> subvert the controls by loading a misconfigured or malicious OS that
> would send the wrong security context.
> 
> Things do get more complicated if you want to allow some sharing between
> marketing and development; the real point I'm trying to make is that
> gnome-user-share is just a technology for sharing files and there's no
> fundamental reason it couldn't be enhanced to work better in a managed
> corporate environment as long as it doesn't cost the user experience of
> the other use cases (friends in coffee shops, etc.).

Once all the above is possible, then perhaps it could be looked at.
However SELinux really does get in the way of users doing work right
now.  Yes I know lots of work is being done on SELinux but the sad truth
is that it isn't really usable in a corporate environment with lots of
users (and uses) without having a couple of full time SELinux managers
on staff.  Not very realistic.

> > I'm afraid I lack the knowledge of GConf to understand this statement.
> > Do you mean that it will default to off?
> 
> The default chosen is unrelated to the use of GConf technology; I think
> if it was included in Fedora it would default to on.

This is what I oppose.  Especially if the end user doesn't really know
about it.

> > My users would be fired if they opened up a unauthenticated share in a
> > coffee shop.  Scp, usb fob, https w/ authentication, something along
> > those lines.  Not everybody works in an environment where it is OK if
> > somebody outside the company gets a hold of source code that is being
> > worked on.
> 
> This doesn't make much sense to me; it isn't gnome-user-share's fault if
> a user drops a confidential document in ~/Public any more than it's
> Evolution's fault if they email it to evilcracker at example.com.
>
> If your users have their own laptops that they use for work, I would
> expect to be able to use my own laptop to drop a picture in my ~/Public
> to share with a friend at a coffee shop; I'd expect the company to trust
> me not to do this with confidential data.
> 
> Now if your company owns the laptops you can do what you want, the
> expectation being that users will not do non-work-related things with
> their laptops.  But if you were to turn off gnome-user-share, in
> parallel you should also configure Evolution to not allow sending email
> to non-work addresses with attachments...

Sure we have to trust our users.  However it's a conscious effort to
email code to a person.  It's unconscious to forget that there is
sensitive material sitting in Public from when in the office and when
you open your laptop at a coffee shop, whoops there it is.  Users can
forget easily.  This is why it needs to stay off.  Useful in one context
== extremely dangerous in another.  Unless it can 'sense' contexts and
disable it self when outside a corp network.... no not even then because
IMHO no corp network can be trusted to do unauthenticated shares.
Period.

> > What port then?  Will the system 'automatically' open this port on the
> > user configured firewall, because the system thinks that it should be
> > open (much like cups)?
> 
> I think it's incompatible with the firewall.  Personally I turned off
> the firewall long ago; I don't think it provides much security really.
> That's a whole other flamewar though =)
> 
> (let's please not go there now...)

Sure, but if the user can enable it themselves, I'd like to have a
firewall rule to block it that only root can alter.  Just to protect
users from themselves.  As long as the app doesn't open the firewall for
it, than we're OK on this front.

> > I guess bottom line is that this technology might be useful in some
> > environments.  However it poses a (IMHO severe) security risk in many
> > other environments and I'd like to see Fedora continue the train of
> > thought to turn off potentially security risky services by default and
> > make the user make a conscious decision to turn the service back on. 
> 
> I'd rather make Fedora a usable, general purpose desktop OS by default;
> for managed corporate environments there are always going to be a lot of
> tweaks to make; disabling gnome-user share (or changing its config)
> would just be one more.

I'd rather make Fedora a Linux distribution that is secure by default
and can be expanded to be more insecure and 'easier' to share when
necessary.  Linux was attractive to me and lots of others because of the
idea of security first, and in a lot of cases, security over usability.
Please lets not go into the direction where we have Fedora, and then we
have 400 'tweaks' to get to a 'Secure Fedora'.

> >  I
> > also hope that any UI designed to manage this service requires a root
> > password so that joe user couldn't override an administrative setting to
> > disable this service (especially if it fiddles w/ the firewall once
> > enabled).
> 
> Ugh!  You can tell GConf to have a 'mandatory' flag for a key so that
> user applications aren't supposed to be able to change it (the idea is
> in the UI it would be greyed out); but there's nothing (short of
> SELinux) preventing a compromised or buggy application from ignoring the
> flag and exec()ing gnome-user-share or whatever.

I guess this is a step that must be taken to make Fedora usable in
corporate environments.  I just hate to see the distro take this
direction.  I would also hope that this functionality could be provided
by a package, so that the package could just be excluded from
installation and then there is no possible way for a user to enable it.

> All of our desktop work is predicated on the idea that the user doesn't
> know the root password.  You should never need that to get work done.

But you should know it before being able to start sharing services on
the system.  Of course if there is a firewall set, then the user still
couldn't compile apache in /home/ and start it on a port because the
firewall will block them.

I think we disagree on goals to keep in mind w/ the furtherment of
Fedora.  I think as a sysadmin, you obviously think as a desktop user.
Not that either of these views are wrong, it is just they are different
views and have different goals.  A balance must be found.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From walters at redhat.com  Sun Jul 17 19:16:34 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 15:16:34 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <20050717211004.6049aef8@nausicaa.camperquake.de>
References: <42D5743A.6010300@shahms.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
	<20050717205916.3721678f@nausicaa.camperquake.de>
	<1121627132.28161.97.camel@nexus.verbum.private>
	<20050717211004.6049aef8@nausicaa.camperquake.de>
Message-ID: <1121627794.28161.102.camel@nexus.verbum.private>

On Sun, 2005-07-17 at 21:10 +0200, Ralf Ertzinger wrote:
> Hi.
> 
> Colin Walters <walters at redhat.com> wrote:
> 
> > Sure, that makes sense. It would keep everyone else from seeing a lot of
> > empty shares, too.
> 
> An option to "Enable just for this session" would be nice, too.

That gets into the whole problem of defining a "session".  Most people
with laptops suspend instead of logging out for example.  You might
define "session" as between suspends, but that would be annoying if I
was working at my cube, got called to a meeting, closed my laptop
(causing it to suspend), reopened it 30 feet away at the meeting room
(unsuspend), and people were no longer able to access my files.






From jkeating at j2solutions.net  Sun Jul 17 19:16:47 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 12:16:47 -0700
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121627132.28161.97.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
	<20050717205916.3721678f@nausicaa.camperquake.de>
	<1121627132.28161.97.camel@nexus.verbum.private>
Message-ID: <1121627807.2769.46.camel@yoda.loki.me>

On Sun, 2005-07-17 at 15:05 -0400, Colin Walters wrote:
> I just don't like the idea of a totally non-discoverable feature that
> users have to dig through GConf or something to enable.
> 

So make a UI preferences for the (admin)user to enable it.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From fedora at camperquake.de  Sun Jul 17 19:19:34 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 17 Jul 2005 21:19:34 +0200
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121627794.28161.102.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
	<20050717205916.3721678f@nausicaa.camperquake.de>
	<1121627132.28161.97.camel@nexus.verbum.private>
	<20050717211004.6049aef8@nausicaa.camperquake.de>
	<1121627794.28161.102.camel@nexus.verbum.private>
Message-ID: <20050717211934.488087be@nausicaa.camperquake.de>

Hi.

Colin Walters <walters at redhat.com> wrote:

> > An option to "Enable just for this session" would be nice, too.
> 
> That gets into the whole problem of defining a "session".  Most people
> with laptops suspend instead of logging out for example.

I was under the impression that suspending did not work, anyway. But
I meant session in the "graphical login to logout"-sense.

-- 
Q: Why did the monkey fall out of the tree?
A: He was dead stupid!



From jkeating at j2solutions.net  Sun Jul 17 19:21:41 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 12:21:41 -0700
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <42DAAC15.4060904@redhat.com>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<42DAA841.4090106@redhat.com>
	<1121626512.28161.93.camel@nexus.verbum.private>
	<42DAAC15.4060904@redhat.com>
Message-ID: <1121628101.2769.51.camel@yoda.loki.me>

On Mon, 2005-07-18 at 00:35 +0530, Rahul Sundaram wrote:
> Auto enabling on demand with a dialog explaining it a short manner (help 
> for more details) unless administrator restricts it seems to be a good 
> thing to do too
> regards
> Rahul

This seems somewhat sane.  I still think it would be very very easy to
forget that it is there, and bad things happen when you go to a shared
work environment such as a coffee shop or a lan party or something like
that.  It is easy to forget that you have a share open to the whole
world and whatever files you may have placed in there.

How crazy would it be to have a share timeout on this, with a panel icon
to represent whether or not the share is active?  Say set a default
timeout of 1 hour or so?  Then the user would have to click the icon,
and select 're-enable share' for it to be live again.  Of course a
configurable timeout could be used, even (gasp) none. 

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From walters at redhat.com  Sun Jul 17 19:43:53 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 15:43:53 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121627721.2769.44.camel@yoda.loki.me>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<1121627721.2769.44.camel@yoda.loki.me>
Message-ID: <1121629434.28161.130.camel@nexus.verbum.private>

On Sun, 2005-07-17 at 12:15 -0700, Jesse Keating wrote:

> Once all the above is possible, then perhaps it could be looked at.
> However SELinux really does get in the way of users doing work right
> now.  Yes I know lots of work is being done on SELinux but the sad truth
> is that it isn't really usable in a corporate environment with lots of
> users (and uses) without having a couple of full time SELinux managers
> on staff.  Not very realistic.

Those are bugs; something we should be working to fix.

> This is what I oppose.  Especially if the end user doesn't really know
> about it.

I think the discussion in the other subthread about a warning/enable
dialog is sufficient, no?

> Sure we have to trust our users.  However it's a conscious effort to
> email code to a person.  It's unconscious to forget that there is
> sensitive material sitting in Public from when in the office 

I dunno; the idea is you wouldn't want users to use it for sensitive
material.  If you don't trust your users not to put sensitive material
in it you could disable it.  I guess that's your decision.

> I'd rather make Fedora a Linux distribution that is secure by default
> and can be expanded to be more insecure and 'easier' to share when
> necessary. 

I just don't agree that having gnome-user-share available and having
users being able to enable it by default in Fedora (including either
poking a hole in the firewall or simply not having a firewall) is a
security problem in general.  For non-managed environments like a
personal laptop it should just work.

>  Linux was attractive to me and lots of others because of the
> idea of security first, and in a lot of cases, security over usability.
> Please lets not go into the direction where we have Fedora, and then we
> have 400 'tweaks' to get to a 'Secure Fedora'.

I think this particular security is specific to a managed corporate
environment, and in that case there are definitely other tweaks you're
going to be making.

> I guess this is a step that must be taken to make Fedora usable in
> corporate environments.  I just hate to see the distro take this
> direction.  I would also hope that this functionality could be provided
> by a package, so that the package could just be excluded from
> installation and then there is no possible way for a user to enable it.

Sure, removing the package is one way you (the system administrator)
could disable it.

> But you should know it before being able to start sharing services on
> the system. 

It seems totally arbitrary to me; why shouldn't you need the root
password to send email then?  Clearly we could do that either using
SELinux or the firewall.

The whole "we prompted the user for the root password, therefore we can
wash our hands of responsibility if anything goes wrong" mentality is
wrong, IMO.  We should get things to the point where the right thing
happens and the root password is never involved.  In this case, I think
the right thing is the first-time warning dialog.

>  Of course if there is a firewall set, then the user still
> couldn't compile apache in /home/ and start it on a port because the
> firewall will block them.

If your user is actively malicious they could simply send an email with
the data.

> I think we disagree on goals to keep in mind w/ the furtherment of
> Fedora.  I think as a sysadmin, you obviously think as a desktop user.
> Not that either of these views are wrong, it is just they are different
> views and have different goals. 

Yes; I think this has been a useful discussion.  I appreciate getting
your perspective as a sysadmin using Fedora.  I guess my bottom line
here is:

Since for the managed corporate environment you clearly do other tweaks
such as making a samba share appear on the desktop, is it so bad for you
(if you don't trust your users and want to disable g-u-s) to set a
mandatory GConf key to disable it?  Probably Sabayon could be enhanced
to make this doable from a GUI too (perhaps in the Sabayon window when
you click on the Public folder you get an option to disable sharing).




From sundaram at redhat.com  Sun Jul 17 19:50:08 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 01:20:08 +0530
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121629434.28161.130.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<604aa79105071515053d280939@mail.gmail.com>	<1121495640.11210.107.camel@dimi>	<1121496640.22208.5.camel@localhost.localdomain>	<1121497995.11210.127.camel@dimi>	<1121526729.4036.102.camel@nexus.verbum.private>	<1121530528.11210.163.camel@dimi>	<1121534792.27612.12.camel@nexus.verbum.private>	<1121568064.3273.2.camel@localhost.localdomain>	<1121614603.28161.17.camel@nexus.verbum.private>	<1121622903.2769.25.camel@yoda.loki.me>	<1121625681.28161.85.camel@nexus.verbum.private>	<1121627721.2769.44.camel@yoda.loki.me>
	<1121629434.28161.130.camel@nexus.verbum.pri! vate>
Message-ID: <42DAB670.9040705@redhat.com>

HI

>Since for the managed corporate environment you clearly do other tweaks
>such as making a samba share appear on the desktop, is it so bad for you
>(if you don't trust your users and want to disable g-u-s) to set a
>mandatory GConf key to disable it?  Probably Sabayon could be enhanced
>to make this doable from a GUI too (perhaps in the Sabayon window when
>you click on the Public folder you get an option to disable sharing).
>  
>
While we are pushing all this as something sabayon is or could be 
capable of somebody should send the feedback to the sabayon lists if its 
not read here by the relevant developers already.  One of the reasons 
the dicussions are better done in the right place(TM)

regards
Rahul



From davej at redhat.com  Sun Jul 17 20:35:40 2005
From: davej at redhat.com (Dave Jones)
Date: Sun, 17 Jul 2005 16:35:40 -0400
Subject: rawhide report: 20050702 changes
In-Reply-To: <a36b7e2a0507161411124e0e2b@mail.gmail.com>
References: <200507021108.j62B8Jd5008890@porkchop.devel.redhat.com>
	<a36b7e2a0507161411124e0e2b@mail.gmail.com>
Message-ID: <20050717203540.GC32622@redhat.com>

On Sat, Jul 16, 2005 at 04:11:44PM -0500, Justin Conover wrote:
 > On 7/2/05, Build System <buildsys at redhat.com> wrote:
 > > 
 > > 
 > > 
 > > Updated Packages:
 > 
 > > kernel-2.6.12-1.1411_FC5
 > > ------------------------
 > > * Fri Jul 01 2005 Dave Jones <davej at redhat.com>
 > > - 2.6.13-rc1-git3
 > >   - Xen broke again, so is temporarily disabled. Sorry :(
 > > - Add a vdso marker to /proc/*/maps even if the vDSO is randomized
 > > 
 > > * Thu Jun 30 2005 Dave Jones <davej at redhat.com>
 > > - 2.6.13-rc1-git2
 > > 
 > > * Wed Jun 29 2005 Dave Jones <davej at redhat.com>
 > > - 2.6.13-rc1
 > > 
 > 
 > It's been a couple weeks, what broke on the xen kernels and is there
 > anyway to get it working again?
 
Rik was working on an update to a newer upstream Xen snapshot
last week, but this week is pretty much going to be nothing
but kernel-summit/OLS activities, so I wouldn't expect it
to start working for at least another week or so.

		Dave



From Nicolas.Mailhot at laPoste.net  Sun Jul 17 20:37:28 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 22:37:28 +0200
Subject: No more right click terminal
In-Reply-To: <1121360055.31376.78.camel@prometheus.gamehouse.com>
References: <1121248417.16074.19.camel@goose>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>  <20050714125454.GC3984@redhat.com>
	<1121360055.31376.78.camel@prometheus.gamehouse.com>
Message-ID: <1121632648.30856.22.camel@rousalka.dyndns.org>

Le jeudi 14 juillet 2005 ? 09:54 -0700, Jesse Keating a ?crit :

> What users could hope for is that those representatives of the Gnome
> development group within @redhat could be the voice of @redhat's users,
> so that the gnome group doesn't get more and more joe-random-opinion (of
> which to ignore), they can get a more aggregated user base opinion from
> vendor representatives.

+1

Red Hat involvement in Gnome is both older and deeper than in some of
the projects that have been officially blessed in this thread.

Moreover a distribution is not merely a build farm. A distribution is
about gracefully integrating software bricks. Good defaults are
distribution decisions first and upstream ones second - full GUI may be
good at the Gnome level, but at the distribution level with all the text
apps it's madness.

(and I won't even write about RHEL which serves as the foundation of
various closed apps that haven't moved out of GTK1 land yet, and will
start registering in the Gnome menu in 5 years at best)

Alternatively we can move to a fully Gnomified Fedora and excise
forcefully all non-gnome apps, as I'm sure this is fully in line with
the aims of whoever decided to remove this menu entry?

? Stupid proposal to show how upstream best interests are not always the
ones of the distribution

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/d16916e2/attachment.sig>

From jspaleta at gmail.com  Sun Jul 17 20:46:24 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 17 Jul 2005 16:46:24 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <1121629434.28161.130.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<1121627721.2769.44.camel@yoda.loki.me>
	<1121629434.28161.130.camel@nexus.verbum.private>
Message-ID: <604aa791050717134626ebe0a@mail.gmail.com>

On 7/17/05, Colin Walters <walters at redhat.com> wrote:
> > This is what I oppose.  Especially if the end user doesn't really know
> > about it.
> 
> I think the discussion in the other subthread about a warning/enable
> dialog is sufficient, no?

tieing the sharing feature into networkmanager somehow so you can get
a re-warning/re-notification about sharing being enabled when you
switch to another network might make some sense long term.  Of if you
can go further and make it enablable for some networks but not others.

> Sure, removing the package is one way you (the system administrator)
> could disable it.

Is this a commitment to make sure this is treated as a addon
package... instead of making a more fundamental default desktop
element explicitly requiring the package that provides this sharing
functionality?  In the past, some elements of the gnome desktop as
packaged in fedora/rhl could be considered as addon functionality
where packaged in a way that demanded they always get installed via
explicit added requirements to ensure an expected default experience. 
  If whatever package provides this file sharing functionality ends up
being explicitly required in something like gnome-session or nautilus
this makes it very difficult for an admin to remove without going to
extreme effort to rebuild Core gnome removing the explicitly added
requirements.

-jef



From Nicolas.Mailhot at laPoste.net  Sun Jul 17 20:50:05 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 22:50:05 +0200
Subject: No more right click terminal
In-Reply-To: <604aa79105071406403094ff4c@mail.gmail.com>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>
	<1121272795.13335.18.camel@localhost.localdomain>
	<1121282867.21244.27.camel@rousalka.dyndns.org>
	<42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
Message-ID: <1121633406.30856.32.camel@rousalka.dyndns.org>

Le jeudi 14 juillet 2005 ? 09:40 -0400, Jeff Spaleta a ?crit :

> My personal feelings on the matter are that people who refuse to move
> discussion to the most effective upstream forum, are delibrately
> attempting to cause problems or are only interested in browbeating
> other people with their opinions in an effort to score debating
> experience points.  Once an issue or complaint is brought it... the
> quicker it can be moved to the appropriate upstream  forum or group
> the less frustrating it is for everyone.

My personal feeling is you can't expect Fedora users to learn the
arcanes of every upstream project Fedora uses to interact directly with
it. And if as some people wrote expecting _Red_Hat_ people to follow
_Red_Hat_ lists is impractical, how practical it is to expect every
single Fedora user to follow all the Gnome, Mozilla, Open Office...
lists ?

If they did (and test-builded pre-releases to follow changes) why would
they even bother with a distribution ?

I'd rather have one or two Red Hat/Fedora people read the lists and
attract the attention of the various Red Hat groups to relevant threads.
That'd be much more productive for everyone involved.

The non-forking goal of Fedora is commendable. It is the right thing in
the long term. But it won't be achieved by systematically refusing to
mediate between the project users and upstream.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/172def0b/attachment.sig>

From sundaram at redhat.com  Sun Jul 17 20:51:03 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 02:21:03 +0530
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <604aa791050717134626ebe0a@mail.gmail.com>
References: <42D5743A.6010300@shahms.com>	<1121526729.4036.102.camel@nexus.verbum.private>	<1121530528.11210.163.camel@dimi>	<1121534792.27612.12.camel@nexus.verbum.private>	<1121568064.3273.2.camel@localhost.localdomain>	<1121614603.28161.17.camel@nexus.verbum.private>	<1121622903.2769.25.camel@yoda.loki.me>	<1121625681.28161.85.camel@nexus.verbum.private>	<1121627721.2769.44.camel@yoda.loki.me>	<1121629434.28161.130.camel@nexus.verbum.private>
	<604aa791050717134626ebe0a@mail.gmail.com>
Message-ID: <42DAC4B7.6020706@redhat.com>

Hi

>Is this a commitment to make sure this is treated as a addon
>package... instead of making a more fundamental default desktop
>element explicitly requiring the package that provides this sharing
>functionality? 
>
Yes definitely though something could be build on top of this which 
would in turn have it as a dependency

> In the past, some elements of the gnome desktop as
>packaged in fedora/rhl could be considered as addon functionality
>where packaged in a way that demanded they always get installed via
>explicit added requirements to ensure an expected default experience. 
>  
>
This should probably be discussed on a case by case basis

regards
Rahul



From sundaram at redhat.com  Sun Jul 17 20:53:41 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 02:23:41 +0530
Subject: No more right click terminal
In-Reply-To: <1121632648.30856.22.camel@rousalka.dyndns.org>
References: <1121248417.16074.19.camel@goose>	<55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org>	<1121272795.13335.18.camel@localhost.localdomain>	<1121282867.21244.27.camel@rousalka.dyndns.org>	<42D5743A.6010300@shahms.com>	<1121287685.28486.18.camel@rousalka.dyndns.org>	<604aa79105071314411dc3a1ac@mail.gmail.com>	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>
	<20050714125454.GC3984@redhat.com>	<1121360055.31376.78.camel@prometheus.gamehouse.com>
	<1121632648.30856.22.camel@rousalka.dyndns.org>
Message-ID: <42DAC555.8070301@redhat.com>

Nicolas Mailhot wrote:

>Le jeudi 14 juillet 2005 ? 09:54 -0700, Jesse Keating a ?crit :
>
>  
>
>>What users could hope for is that those representatives of the Gnome
>>development group within @redhat could be the voice of @redhat's users,
>>so that the gnome group doesn't get more and more joe-random-opinion (of
>>which to ignore), they can get a more aggregated user base opinion from
>>vendor representatives.
>>    
>>
>
>+1
>
>Red Hat involvement in Gnome is both older and deeper than in some of
>the projects that have been officially blessed in this thread.
>
>Moreover a distribution is not merely a build farm. A distribution is
>about gracefully integrating software bricks. Good defaults are
>distribution decisions first and upstream ones second - full GUI may be
>good at the Gnome level, but at the distribution level with all the text
>apps it's madness.
>
>(and I won't even write about RHEL which serves as the foundation of
>various closed apps that haven't moved out of GTK1 land yet, and will
>start registering in the Gnome menu in 5 years at best)
>  
>
Not just proprietary applications. Many open source projects like the 
loki installer will probably never move out of GTK1. ABI/API 
compatibility isnt just about proprietary apps at all. Thats another 
dicussion that should happen in a different thread though.

>Alternatively we can move to a fully Gnomified Fedora and excise
>forcefully all non-gnome apps, as I'm sure this is fully in line with
>the aims of whoever decided to remove this menu entry?
>
>? Stupid proposal to show how upstream best interests are not always the
>ones of the distribution
>
>  
>
I agree with all of this. I have cited places where blindly following 
upstream is *not* the right policy but in this case I think the decision 
is pretty focussed on the target audience which doesnt include people 
involved  like any kind of development or system adminstration task. 
Again if people have good use cases for including the option by default 
in the desktop context menu I dont think anybody would turn a blind eye 
towards that. Remember every feature has a associated cost. See HP's 
article on this

http://ometer.com/features.html

regards
Rahul



From Nicolas.Mailhot at laPoste.net  Sun Jul 17 21:00:22 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 23:00:22 +0200
Subject: No more right click terminal
In-Reply-To: <20050715205540.GA5910@orient.maison.moi>
References: <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
Message-ID: <1121634022.30856.39.camel@rousalka.dyndns.org>

Le vendredi 15 juillet 2005 ? 22:55 +0200, Emmanuel Seyman a ?crit :
> On Fri, Jul 15, 2005 at 01:20:41PM -0700, Jesse Keating wrote:
> > 
> > End result?  Community and target users do see that maintainers care and
> > listen and try for the end user's best interest.
> 
> Try: Maintainer's head explodes from the amount of work this implies.
> 
> Your case implies that complaining to the maintainer is easier
> than complaining upstream. Why would this be true ?

Because the maintainer knows both upstream and the Fedora context. I see
you've never tried explaining a windows OO.o developer why using the
third mouse button (real or simulated) was better than directly 

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/58b1d5b3/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Sun Jul 17 21:12:56 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 23:12:56 +0200
Subject: No more right click terminal
In-Reply-To: <1121459914.25236.26.camel@localhost.localdomain>
References: <42D5743A.6010300@shahms.com>
	<1121287685.28486.18.camel@rousalka.dyndns.org>
	<604aa79105071314411dc3a1ac@mail.gmail.com>
	<1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715201537.GA14049@srv01.cluenet.de>
	<1121459914.25236.26.camel@localhost.localdomain>
Message-ID: <1121634776.30856.47.camel@rousalka.dyndns.org>

Le vendredi 15 juillet 2005 ? 14:38 -0600, Stuart Jansen a ?crit :

> I'd rather see the Fedora developers fight bugs than aggregate user
> requests and write patches. If you were paying for their services, I
> could see making demands of maintainers.

If we were in the closed source commercial software corporation world
you seem to write about, the software corporation would be expending
huge sums of money to collect the kind of feedback Red Hat gets for free
here. A paying customer expects his wishes to be guessed by his software
provider - he's not paying big bucks to serve as beta tester.

Don't make the mistake of all the analysts that equate FOSS with
charities. It isn't.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/1eece43f/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Sun Jul 17 21:32:02 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 23:32:02 +0200
Subject: No more right click terminal
In-Reply-To: <1121462167.4036.32.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
Message-ID: <1121635922.30856.54.camel@rousalka.dyndns.org>

Le vendredi 15 juillet 2005 ? 17:16 -0400, Colin Walters a ?crit :
> On Thu, 2005-07-14 at 14:32 -0300, Alexandre Oliva wrote:
> > On Jul 13, 2005, Colin Walters <walters at redhat.com> wrote:
> > 
> > > Think of it this way: what if GNOME's historical audience had been
> > > musicians?  Then the right click menu might have had 
> > > "Open Musical Score Composer".  Having that makes as much sense to the
> > > general population as "Open Terminal" does.
> > 
> > FWIW, when I first introduced Cygwin to a musician friend of mine, he
> > absolutely *loved* the ability to issue commands without having to
> > point and click, and the ability to write scripts to automate common
> > or repetitive tasks.
> 
> If your friend can write scripts, that means he or she has a level of
> technical knowledge we can not expect of all users.

My mother used DOS commands to load fonts in her printer back when it
was necessary. She'll still use any series of command I'll write down
for her.

On the other hand she does not know what a "window" or a "click" are
despite working all day in a GUI. If I ever try to explain her anything
that involves the GUI she'll get mad at me because she does not know how
the various GUI objects are named (or behave) and does not want to
learn. 

Terminals are not about technical users. Sometimes they're the only tool
for total computer illiterates.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/9bffdfea/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Sun Jul 17 21:41:03 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 23:41:03 +0200
Subject: No more right click terminal
In-Reply-To: <42D843DF.9000308@redhat.com>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
	<42D843DF.9000308@redhat.com>
Message-ID: <1121636464.30856.60.camel@rousalka.dyndns.org>

Le samedi 16 juillet 2005 ? 04:46 +0530, Rahul Sundaram a ?crit :
> Hi
> 
> >Regardless of how you get there (right click, application menu,
> >CTRL+ALT+F1) using the command line is NOT a bug.

> Definitely not a bug. I use a terminal all the time too. 
> Non-developer/non-sysadmin is the keyword to note here from Colin's argument

And unfortunately it's a bad distinction.
The real one is repetitive/non repetitive tasks.
Anything repetitive will always be better served by a rigid interface
like a terminal, not something as changing as the GUI.

Just go look at any POS system - you'll never find even such a basic
thing as a mouse cursor. And the people using them have no CS doctorates
(at least most of them)

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/c90aabe6/attachment.sig>

From sundaram at redhat.com  Sun Jul 17 21:44:35 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 03:14:35 +0530
Subject: No more right click terminal
In-Reply-To: <1121636464.30856.60.camel@rousalka.dyndns.org>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>	<42D843DF.9000308@redhat.com>
	<1121636464.30856.60.camel@rousalka.dyndns.org>
Message-ID: <42DAD143.8030300@redhat.com>

Hi

>And unfortunately it's a bad distinction.
>The real one is repetitive/non repetitive tasks.
>Anything repetitive will always be better served by a rigid interface
>like a terminal, not something as changing as the GUI.
>  
>
Not necessarily. Openoffice.org macros for examples are GUI scripts for 
precisely such things which are repetitive. Colin also mention that 
having something Apple script would be a good thing to have them

>Just go look at any POS system
>
You mean piece of shit systems ;-)

> - you'll never find even such a basic
>thing as a mouse cursor. And the people using them have no CS doctorates
>(at least most of them)
>  
>
Ya but such people wouldnt need a terminal option at all either

regards
Rahul



From lamont at gurulabs.com  Sun Jul 17 21:51:01 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Sun, 17 Jul 2005 15:51:01 -0600
Subject: No more right click terminal
In-Reply-To: <1121619285.28161.25.camel@nexus.verbum.private>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>
	<e692861c05071609426c63f8ea@mail.gmail.com>
	<1121619285.28161.25.camel@nexus.verbum.private>
Message-ID: <200507171551.05891.lamont@gurulabs.com>

On Sunday 17 July 2005 10:54am, Colin Walters wrote:
[SNIP]
> Not knowing how to use a terminal does not mean you have "substantially
> diminished mental capacity".
>
> I have several mathematician friends who can run intellectual circles
> around me in a number of areas (even besides math) like philosophy and
> literature, but don't know or care how computers work.
>
> The idea is to design the desktop for people who want to use the
> computer to get work done (sending email, writing documents, etc), not
> learn how it works.

Does that mean that the only people the desktop is designed for are those who 
"...don't know or care how computers work." ?

I use a lot of GUI apps that some of these people would never have heard of 
(like Kdevelop, dia, lincvs, Brahms, etc.)  I am a user, too.  But I also 
happen to be able to write good software and good documentation and (not 
always so good :) stories and email and music and...

I guess I'm asking, why should the desktop be designed for those who only use 
the "cube-farm" basics?

One possible answer:  So GNOME wants to be all things to the little people who 
don't know nor care to know?  That's fine.  This is open source.  
"$open_source == $freedom_of_choice;" .  So, I will vote with my "feet", 
a.k.a. my choice of desktop.  I use KDE.

Maybe instead of trying to get the Fedora Development community to make GNOME 
what developers want it to be, there should be more choices made available.  
Adding fluxbox, blackbox, openbox & evilwm to the core distribution would not 
be difficult and would only take up less than 2MB on the CDs.  Others (like 
Enlightenment and some of the cool new 3D desktop environments) could easily 
live in Extras.  Why don't we look at providing more options for those who 
care?  (Yes, I know some of them are already in Extras).

Personally, I like having the "Open Terminal" context menu item by default; 
it's there for those who need it/know about it/like it.  For those who would 
prefer to open their terminals another way, they can press <ALT>+<F2>, drill 
the menus until you find it, plop a launcher somewhere or drop the GUI 
entirely.  But the choice was still ours.  For those who do not understand 
what they are looking at after clicking "Open Terminal" what's the worst they 
can do?  This is Linux, they can't blow up the system (at least, not unless 
the sysadmin is a true moron).  The security of the system prevents them from 
do damage other than to themselves.

However it happened, that menu item is gone, so I will either have to live 
with yet another frustration when I am "forced" to use GNOME or install some 
extra package or ???  I think it would be good if the new-and-improved 
version of the "Open Terminal" context menu item were part of Core.  However, 
that is an issue for the packagers mailing list.  Right?
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/851b2737/attachment.sig>

From sundaram at redhat.com  Sun Jul 17 21:56:34 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 03:26:34 +0530
Subject: No more right click terminal
In-Reply-To: <200507171551.05891.lamont@gurulabs.com>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>	<e692861c05071609426c63f8ea@mail.gmail.com>	<1121619285.28161.25.camel@nexus.verbum.private>
	<200507171551.05891.lamont@gurulabs.com>
Message-ID: <42DAD412.9060105@redhat.com>

Hi

>
>One possible answer:  So GNOME wants to be all things to the little people who 
>don't know nor care to know?  That's fine.  This is open source.  
>"$open_source == $freedom_of_choice;" .  So, I will vote with my "feet", 
>a.k.a. my choice of desktop.  I use KDE.
>  
>
KDE doesnt have a terminal in the desktop context menu either.

>Maybe instead of trying to get the Fedora Development community to make GNOME 
>what developers want it to be, there should be more choices made available.  
>Adding fluxbox, blackbox, openbox & evilwm to the core distribution would not 
>be difficult and would only take up less than 2MB on the CDs.  Others (like 
>Enlightenment and some of the cool new 3D desktop environments) could easily 
>live in Extras.  Why don't we look at providing more options for those who 
>care?  (Yes, I know some of them are already in Extras).
>  
>
Its not about size. its about maintenance. Why do want everything but 
the kitchen sink in core itself?

>Personally, I like having the "Open Terminal" context menu item by default; 
>it's there for those who need it/know about it/like it.  
>
Fedora core 5 would have a yum aware anaconda 
(http://www.fedoraproject.org/wiki/Anaconda/YumBackend) and will allow 
you to choose nautilus-open-terminal to do that from extras. Use 
kickstart if you want to automate this process for N number of systems. 
You have the choice.

regards
Rahul



From Nicolas.Mailhot at laPoste.net  Sun Jul 17 21:57:25 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 17 Jul 2005 23:57:25 +0200
Subject: No more right click terminal
In-Reply-To: <1121526729.4036.102.camel@nexus.verbum.private>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
Message-ID: <1121637465.30856.72.camel@rousalka.dyndns.org>

Le samedi 16 juillet 2005 ? 11:12 -0400, Colin Walters a ?crit :
> On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:
> 
> > and removing a generally useful feature way before its time is not
> > helpful.
> 
> The terminal is still available.  From half of the responses on this
> thread you'd think it'd been removed entirely.

It's been moved in menu-land.
I'd say at least 80% of terminal uses by non-tech users is to avoid
dealing with menu-land shifting sands, its continual icon remapping and
menu entry renaming.

If I need evo I know I can open a term and type evolution. This had been
true for several years. Can you say the same about evo gui access ?

It's all well and good to worry about the average user but I'm ready to
bet you anything any given average user study will find the average user
cares more about finding his stuff the same way in the same place than
about the "gui-correctness" of the access method. You can verify it any
day by taking over a windows user desktop and reordering the menu and
root window. Users don't care if it's a mess as long as it's the mess
they're used to.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050717/561234b6/attachment.sig>

From jspaleta at gmail.com  Sun Jul 17 22:12:47 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 17 Jul 2005 18:12:47 -0400
Subject: No more right click terminal
In-Reply-To: <1121636464.30856.60.camel@rousalka.dyndns.org>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
	<42D843DF.9000308@redhat.com>
	<1121636464.30856.60.camel@rousalka.dyndns.org>
Message-ID: <604aa7910507171512204deb52@mail.gmail.com>

On 7/17/05, Nicolas Mailhot <Nicolas.Mailhot at laposte.net> wrote:
> And unfortunately it's a bad distinction.
> The real one is repetitive/non repetitive tasks.
> Anything repetitive will always be better served by a rigid interface
> like a terminal, not something as changing as the GUI.
>
> Just go look at any POS system - you'll never find even such a basic
> thing as a mouse cursor. And the people using them have no CS doctorates
> (at least most of them)

Are you on crack?  There are many POS systems that have 'GUIS" and and
driven by a touch screen interface instead of a "mouse" without
exposing a terminal or a full keyboard.
The existence of a "mouse cursor" is not the definition of a "GUI"  

The WaWa convience store  sub sandwich ordering interface has no
terminal.. no cmdline..it has no keyboard.. but it certaintly is a
"graphical" "user" "interface".. i see normal people use it all the
time... the interface even gives you a nice solid sounding "click"
sound when you press a "button" on the touch screen.  You can do your
whole sandwich order looking at nothing but the graphical depiction of
each sandwich and condiment.. I could have used one of those marvelous
"graphical interfaces" when i was in Budapest back in the day.  No
mouse or mouse cursor because touch screen interfaces that are
designed well  can avoid the  need a mouse and thus the depiction of a
cursor. But it is a GUI... and it is a form of POS.  Additionally Many
of the self-checkout stations in grocery stores in my area also have
"GUI" POS systems that don't expose a commandline or a physical
keyboard or mouse. The have a barcode scanner and a touch screen.. and
a software keyboard to use when the barcode reader fails.
 

-jef"drowning in hyperbole and over-statement"spaleta



From sundaram at redhat.com  Sun Jul 17 22:17:21 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 18 Jul 2005 03:47:21 +0530
Subject: No more right click terminal
In-Reply-To: <1121637465.30856.72.camel@rousalka.dyndns.org>
References: <42D5743A.6010300@shahms.com>
	<1121326118.2792.10.camel@roque>	<604aa791050714051125787aeb@mail.gmail.com>	<1121344610.11210.99.camel@dimi>	<604aa79105071406403094ff4c@mail.gmail.com>	<20050715161541.GF10161@srv01.cluenet.de>	<20050715195945.GA4432@orient.maison.moi>	<1121458841.8029.22.camel@prometheus.gamehouse.com>	<20050715205540.GA5910@orient.maison.moi>	<1121462180.8029.30.camel@prometheus.gamehouse.com>	<604aa79105071515053d280939@mail.gmail.com>	<1121495640.11210.107.camel@dimi>	<1121496640.22208.5.camel@localhost.localdomain>	<1121497995.11210.127.camel@dimi>	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121637465.30856.72.camel@rousalka.dyndns.org>
Message-ID: <42DAD8F1.9010407@redhat.com>

Nicolas Mailhot wrote:

>Le samedi 16 juillet 2005 ? 11:12 -0400, Colin Walters a ?crit :
>  
>
>>On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:
>>
>>    
>>
>>>and removing a generally useful feature way before its time is not
>>>helpful.
>>>      
>>>
>>The terminal is still available.  From half of the responses on this
>>thread you'd think it'd been removed entirely.
>>    
>>
>
>It's been moved in menu-land.
>I'd say at least 80% of terminal uses by non-tech users is to avoid
>dealing with menu-land shifting sands, its continual icon remapping and
>menu entry renaming.
>  
>
That would be a good thing to avoid as much as possible but the value of 
it is sometimes more than the cost.

>If I need evo I know I can open a term and type evolution. This had been
>true for several years. Can you say the same about evo gui access ?
>  
>
Alt+f2 and evolution has been true for several years too but you cant 
seriously argue that typing in GUI applications from the terminal is 
actually the right approach for end users and the one that we need to 
optimize for

>You can verify it any
>day by taking over a windows user desktop and reordering the menu and
>root window. Users don't care if it's a mess as long as it's the mess
>they're used to.
>  
>
Windows does reorganise its menu over revisions. I do agree GNOME seems 
to be doing it a a bit more. I think settling down on one idea and 
retaining that over a longer period of time is a good thing too

regards
Rahul



From johnp at redhat.com  Sun Jul 17 22:20:57 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Sun, 17 Jul 2005 18:20:57 -0400
Subject: End of thread (was Re: No more right click terminal)
In-Reply-To: <1121637465.30856.72.camel@rousalka.dyndns.org>
References: <42D5743A.6010300@shahms.com> <1121326118.2792.10.camel@roque>
	<604aa791050714051125787aeb@mail.gmail.com>
	<1121344610.11210.99.camel@dimi>
	<604aa79105071406403094ff4c@mail.gmail.com>
	<20050715161541.GF10161@srv01.cluenet.de>
	<20050715195945.GA4432@orient.maison.moi>
	<1121458841.8029.22.camel@prometheus.gamehouse.com>
	<20050715205540.GA5910@orient.maison.moi>
	<1121462180.8029.30.camel@prometheus.gamehouse.com>
	<604aa79105071515053d280939@mail.gmail.com>
	<1121495640.11210.107.camel@dimi>
	<1121496640.22208.5.camel@localhost.localdomain>
	<1121497995.11210.127.camel@dimi>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121637465.30856.72.camel@rousalka.dyndns.org>
Message-ID: <1121638857.21813.79.camel@localhost.localdomain>

Please end this thread now.  People are arguing in circles and you know
what, no minds are going to be changed.  I think anyone who cared has
gotten their say and it has all become noise after that.  Please refrain
from posting to this thread.  If you really want to continue this take
it off list.

On Sun, 2005-07-17 at 23:57 +0200, Nicolas Mailhot wrote:
> Le samedi 16 juillet 2005 ? 11:12 -0400, Colin Walters a ?crit :
> > On Sat, 2005-07-16 at 03:13 -0400, Dimi Paun wrote:
> > 
> > > and removing a generally useful feature way before its time is not
> > > helpful.
> > 
> > The terminal is still available.  From half of the responses on this
> > thread you'd think it'd been removed entirely.
> 
> It's been moved in menu-land.
> I'd say at least 80% of terminal uses by non-tech users is to avoid
> dealing with menu-land shifting sands, its continual icon remapping and
> menu entry renaming.
> 
> If I need evo I know I can open a term and type evolution. This had been
> true for several years. Can you say the same about evo gui access ?
> 
> It's all well and good to worry about the average user but I'm ready to
> bet you anything any given average user study will find the average user
> cares more about finding his stuff the same way in the same place than
> about the "gui-correctness" of the access method. You can verify it any
> day by taking over a windows user desktop and reordering the menu and
> root window. Users don't care if it's a mess as long as it's the mess
> they're used to.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
John (J5) Palmieri <johnp at redhat.com>



From i.pilcher at comcast.net  Sun Jul 17 22:48:59 2005
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Sun, 17 Jul 2005 17:48:59 -0500
Subject: No more right click terminal
In-Reply-To: <42DAD412.9060105@redhat.com>
References: <Pine.LNX.4.44.0507151840370.17917-100000@linux>	<e692861c05071609426c63f8ea@mail.gmail.com>	<1121619285.28161.25.camel@nexus.verbum.private>	<200507171551.05891.lamont@gurulabs.com>
	<42DAD412.9060105@redhat.com>
Message-ID: <dben8r$8h8$1@sea.gmane.org>

Rahul Sundaram wrote:
> KDE doesnt have a terminal in the desktop context menu either.

Um, what's that "Konsole..." entry in my desktop context menu?

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From Nicolas.Mailhot at laPoste.net  Sun Jul 17 22:50:41 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 18 Jul 2005 00:50:41 +0200
Subject: No more right click terminal
In-Reply-To: <604aa7910507171512204deb52@mail.gmail.com>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
	<42D843DF.9000308@redhat.com>
	<1121636464.30856.60.camel@rousalka.dyndns.org>
	<604aa7910507171512204deb52@mail.gmail.com>
Message-ID: <1121640642.32143.3.camel@rousalka.dyndns.org>

Le dimanche 17 juillet 2005 ? 18:12 -0400, Jeff Spaleta a ?crit :
> On 7/17/05, Nicolas Mailhot <Nicolas.Mailhot at laposte.net> wrote:
> > And unfortunately it's a bad distinction.
> > The real one is repetitive/non repetitive tasks.
> > Anything repetitive will always be better served by a rigid interface
> > like a terminal, not something as changing as the GUI.
> >
> > Just go look at any POS system - you'll never find even such a basic
> > thing as a mouse cursor. And the people using them have no CS doctorates
> > (at least most of them)
> 
> Are you on crack?  There are many POS systems that have 'GUIS" and and
> driven by a touch screen interface instead of a "mouse" without
> exposing a terminal or a full keyboard.

So what ? They're still closer by an order of magnitude to classical
text apps than to a GUI in the Gnome sense.

They have no windows. They use text everywhere. No icons. etc...

Sometimes they purposefully use a motif-like dark on grey interface
(even if the underlying toolkit is more capable) just because that's
what the operators are used to, and in the real world same as before is
better than changed and slightly improved.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050718/af207379/attachment.sig>

From alan at redhat.com  Sun Jul 17 22:59:23 2005
From: alan at redhat.com (Alan Cox)
Date: Sun, 17 Jul 2005 18:59:23 -0400
Subject: No more right click terminal
In-Reply-To: <1121640642.32143.3.camel@rousalka.dyndns.org>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
	<42D843DF.9000308@redhat.com>
	<1121636464.30856.60.camel@rousalka.dyndns.org>
	<604aa7910507171512204deb52@mail.gmail.com>
	<1121640642.32143.3.camel@rousalka.dyndns.org>
Message-ID: <20050717225923.GE11202@devserv.devel.redhat.com>

On Mon, Jul 18, 2005 at 12:50:41AM +0200, Nicolas Mailhot wrote:
> So what ? They're still closer by an order of magnitude to classical
> text apps than to a GUI in the Gnome sense.

You need to understand why. If you look at UI research you will see that there
are two distinct kinds of interface at work here. The first is one which you
are highly familiar with (eg the checkout). Prompts, guidelines and help are 
buried away in case you forget a detail so that performance is maximised. You
carry the 'conceptual map' in your head.

The other that GUI's more normally reflect is casual use devices. You don't
remember the precise operation but instead the menus and icons on screen guide
you by prompting memories or links with previous experiences or related things
that are not immediately conciously present.

A trained operator can happily look up tickets for flights by typing something
like "LHR>>>YYZ>>>S#" because they do it every day. Its a very different 
interface design goal



From Nicolas.Mailhot at laPoste.net  Sun Jul 17 23:05:54 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 18 Jul 2005 01:05:54 +0200
Subject: No more right click terminal
In-Reply-To: <20050717225923.GE11202@devserv.devel.redhat.com>
References: <Pine.LNX.4.44.0507151806430.17647-100000@linux>
	<42D843DF.9000308@redhat.com>
	<1121636464.30856.60.camel@rousalka.dyndns.org>
	<604aa7910507171512204deb52@mail.gmail.com>
	<1121640642.32143.3.camel@rousalka.dyndns.org>
	<20050717225923.GE11202@devserv.devel.redhat.com>
Message-ID: <1121641554.32394.7.camel@rousalka.dyndns.org>

Le dimanche 17 juillet 2005 ? 18:59 -0400, Alan Cox a ?crit :
> On Mon, Jul 18, 2005 at 12:50:41AM +0200, Nicolas Mailhot wrote:
> > So what ? They're still closer by an order of magnitude to classical
> > text apps than to a GUI in the Gnome sense.
> 
> You need to understand why. If you look at UI research you will see that there
> are two distinct kinds of interface at work here. The first is one which you
> are highly familiar with (eg the checkout). Prompts, guidelines and help are 
> buried away in case you forget a detail so that performance is maximised. You
> carry the 'conceptual map' in your head.
> 
> The other that GUI's more normally reflect is casual use devices. You don't
> remember the precise operation but instead the menus and icons on screen guide
> you by prompting memories or links with previous experiences or related things
> that are not immediately conciously present.
> 
> A trained operator can happily look up tickets for flights by typing something
> like "LHR>>>YYZ>>>S#" because they do it every day. Its a very different 
> interface design goal

Thank you for the explanation. I do understand it. That's why I wrote
the difference was not between technical and non-technical tasks but
between repetitive and non-repetitive (but your message will be better
received than mine I'm sure)

And an awful lot of people that use computers for work not to
chat/play/discover casually their tool fall in the repetitive category.
They're not a technical elite minority. It's a mistake to design an
interface that purposefully ignores their needs.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050718/69296242/attachment.sig>

From walters at redhat.com  Mon Jul 18 00:35:52 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 20:35:52 -0400
Subject: gnome-user-share (was Re: No more right click terminal)
In-Reply-To: <604aa791050717134626ebe0a@mail.gmail.com>
References: <42D5743A.6010300@shahms.com>
	<1121526729.4036.102.camel@nexus.verbum.private>
	<1121530528.11210.163.camel@dimi>
	<1121534792.27612.12.camel@nexus.verbum.private>
	<1121568064.3273.2.camel@localhost.localdomain>
	<1121614603.28161.17.camel@nexus.verbum.private>
	<1121622903.2769.25.camel@yoda.loki.me>
	<1121625681.28161.85.camel@nexus.verbum.private>
	<1121627721.2769.44.camel@yoda.loki.me>
	<1121629434.28161.130.camel@nexus.verbum.private>
	<604aa791050717134626ebe0a@mail.gmail.com>
Message-ID: <1121646952.8275.0.camel@nexus.verbum.private>

On
>   If whatever package provides this file sharing functionality ends up
> being explicitly required in something like gnome-session or nautilus
> this makes it very difficult for an admin to remove without going to
> extreme effort to rebuild Core gnome removing the explicitly added
> requirements.

It would be added in such a way that removing the RPM would remove the
feature.



From jkeating at j2solutions.net  Mon Jul 18 00:46:20 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 17:46:20 -0700
Subject: gnome-user-share
Message-ID: <1121647580.2769.75.camel@yoda.loki.me>

I've started a new thread because this discussion was going to get lost
in the 200+ message thread-o-doom.

So so far we have the introduction of gnome-user-share, which uses an
http process dynamically bound to a port running as the user to share
stuff in a ~/Public file to the world w/out auth. It sounds like
gnome-user-auth will go into core.  The restrictions have been put
forth:

* Functionality is provided by a package and removed by a package, w/out
core deps.

* Functionality is controlled by a gconf entry which an admin can set to
mandatory off (or just remove the package)


Some ideas that have floated for this package include:

* Functionality disabled until a file is placed in ~/Public prompting
for a dialog box informing the user that the share is now active, with a
link to more help in this.

* Gnome-panel icon to show state of sharing with a timeout value to stop
the share (configurable)

* Integration with network-manager to enable/disable the share on
specific networks

Thoughts?  
-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dalive at flashmail.com  Mon Jul 18 01:38:24 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Sun, 17 Jul 2005 21:38:24 -0400
Subject: gnome-user-share
In-Reply-To: <1121647580.2769.75.camel@yoda.loki.me>
References: <1121647580.2769.75.camel@yoda.loki.me>
Message-ID: <42DB0810.8010302@flashmail.com>

Jesse Keating wrote:

>I've started a new thread because this discussion was going to get lost
>in the 200+ message thread-o-doom.
>
>So so far we have the introduction of gnome-user-share, which uses an
>http process dynamically bound to a port running as the user to share
>stuff in a ~/Public file to the world w/out auth. It sounds like
>gnome-user-auth will go into core.  The restrictions have been put
>forth:
>
>* Functionality is provided by a package and removed by a package, w/out
>core deps.
>
>* Functionality is controlled by a gconf entry which an admin can set to
>mandatory off (or just remove the package)
>
>
>Some ideas that have floated for this package include:
>
>* Functionality disabled until a file is placed in ~/Public prompting
>for a dialog box informing the user that the share is now active, with a
>link to more help in this.
>
>* Gnome-panel icon to show state of sharing with a timeout value to stop
>the share (configurable)
>
>* Integration with network-manager to enable/disable the share on
>specific networks
>
>Thoughts?  
>  
>
What protocol will this be using? (http, ftp, tftp, etc)



From jkeating at j2solutions.net  Mon Jul 18 02:08:40 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 19:08:40 -0700
Subject: gnome-user-share
In-Reply-To: <42DB0810.8010302@flashmail.com>
References: <1121647580.2769.75.camel@yoda.loki.me>
	<42DB0810.8010302@flashmail.com>
Message-ID: <1121652521.2769.78.camel@yoda.loki.me>

On Sun, 2005-07-17 at 21:38 -0400, Arthur Pemberton wrote:
> >So so far we have the introduction of gnome-user-share, which uses an
> >http process dynamically bound to a port running as the user to share
> >stuff in a ~/Public file to the world w/out auth. It sounds like
> >gnome-user-auth will go into core.  The restrictions have been put
> >forth:

[...]

> What protocol will this be using? (http, ftp, tftp, etc)

As I stated above, it will be using http.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dalive at flashmail.com  Mon Jul 18 02:15:54 2005
From: dalive at flashmail.com (Arthur Pemberton)
Date: Sun, 17 Jul 2005 22:15:54 -0400
Subject: gnome-user-share
In-Reply-To: <1121652521.2769.78.camel@yoda.loki.me>
References: <1121647580.2769.75.camel@yoda.loki.me>	<42DB0810.8010302@flashmail.com>
	<1121652521.2769.78.camel@yoda.loki.me>
Message-ID: <42DB10DA.9070107@flashmail.com>

Jesse Keating wrote:

>On Sun, 2005-07-17 at 21:38 -0400, Arthur Pemberton wrote:
>  
>
>>>So so far we have the introduction of gnome-user-share, which uses an
>>>http process dynamically bound to a port running as the user to share
>>>stuff in a ~/Public file to the world w/out auth. It sounds like
>>>gnome-user-auth will go into core.  The restrictions have been put
>>>forth:
>>>      
>>>
>
>[...]
>
>  
>
>>What protocol will this be using? (http, ftp, tftp, etc)
>>    
>>
>
>As I stated above, it will be using http.
>
>  
>
Sorry. Would this be a daemon written just for this? or some other 
already written daemon? And would it be chrooted?



From walters at redhat.com  Mon Jul 18 02:16:26 2005
From: walters at redhat.com (Colin Walters)
Date: Sun, 17 Jul 2005 22:16:26 -0400
Subject: gnome-user-share
In-Reply-To: <1121647580.2769.75.camel@yoda.loki.me>
References: <1121647580.2769.75.camel@yoda.loki.me>
Message-ID: <1121652986.8436.3.camel@nexus.verbum.private>

On Sun, 2005-07-17 at 17:46 -0700, Jesse Keating wrote:
> I've started a new thread because this discussion was going to get lost
> in the 200+ message thread-o-doom.
> 
> So so far we have the introduction of gnome-user-share, which uses an
> http process dynamically bound to a port running as the user to share
> stuff in a ~/Public file to the world w/out auth. It sounds like
> gnome-user-auth will go into core.  

I should say that I'm not saying it should go into Core now.  It
actually needs the GNOME Session Services stuff to land before it works
(i.e. without a user needing to drop to a shell and run gnome-user-share
manually).  We're talking GNOME 2.14, not sure if that'll make FC5.

But yes, when it is included, we can discuss these issues.






From rspchan at starhub.net.sg  Mon Jul 18 02:26:17 2005
From: rspchan at starhub.net.sg (RChan)
Date: Mon, 18 Jul 2005 10:26:17 +0800
Subject: PPC kernels: More Pegasos II-friendly kernel config
Message-ID: <42DB1349.2080300@starhub.net.sg>


Hi,

While Pegasos II is not officially support as a PPC platform, some minor 
kernel tweaks
would make it more friendly out-of-the-box for Pegasos II hackers. Would 
the maintainers
kindly consider the following changes:

1. Kernel config
CONFIG_AMIGA_PARTITION=y
CONFIG_SERIO_I8042=y (or m)

(Pegasos II uses AMIGA partitioning and IBM AT PS/2 style mouse and 
keyboard support.)

2. (This part is hard, I'm not sure I understand the issues myself - 
it's necessary to avoid Pegasos II people
from having to rebuild from kernel source.) Pegasos II needs a 
zImage.initrd.chrp kernel to boot (i.e. a combined
zImage.chrp & initrd) instead of a separate vmlinux + initrd, therefore 
some additional object files need to be
distributed with the kernel package. I do not understand exactly why 
yaboot (patched with Amiga partition support)
does not work with separate vmlinux and initrd on Pegasos II so at the 
moment zImage.initrd.chrp is needed.

(Does this make sense?) I need a package which allows me to create a 
zImage.initrd.chrp from vmlinux and a separate
initrd. Debian has a mkvmlinuz deb which attempts to do this - it 
doesn't work for me.
Apparently, some binary .o/.a files that are created during the kernel 
build which lie in arch/ppc/boot (CHRP bootstrap, OpenFirmware
utilities) are combined with vmlinux and a ramdisk image to create 
zImage.initrd.chrp.  I'll try to analyze the build process
a bit more to see what exactly is needed to convert vmlinux + 
ramdisk.image.gz into zImage.initrd.chrp, but I thought I'd
throw this out first for the lists wisdom.

Cheers
Richard





From jkeating at j2solutions.net  Mon Jul 18 03:03:57 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 20:03:57 -0700
Subject: gnome-user-share
In-Reply-To: <42DB10DA.9070107@flashmail.com>
References: <1121647580.2769.75.camel@yoda.loki.me>
	<42DB0810.8010302@flashmail.com>
	<1121652521.2769.78.camel@yoda.loki.me>
	<42DB10DA.9070107@flashmail.com>
Message-ID: <1121655837.2769.80.camel@yoda.loki.me>

On Sun, 2005-07-17 at 22:15 -0400, Arthur Pemberton wrote:
> Sorry. Would this be a daemon written just for this? or some other 
> already written daemon? And would it be chrooted?

The tool itself is being developed by Gnome folks.  I doubt it'll be
chrooted and it will be using apache from what I can gather.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Mon Jul 18 03:04:34 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 17 Jul 2005 20:04:34 -0700
Subject: gnome-user-share
In-Reply-To: <1121652986.8436.3.camel@nexus.verbum.private>
References: <1121647580.2769.75.camel@yoda.loki.me>
	<1121652986.8436.3.camel@nexus.verbum.private>
Message-ID: <1121655875.2769.82.camel@yoda.loki.me>

On Sun, 2005-07-17 at 22:16 -0400, Colin Walters wrote:
> I should say that I'm not saying it should go into Core now.  It
> actually needs the GNOME Session Services stuff to land before it works
> (i.e. without a user needing to drop to a shell and run gnome-user-share
> manually).  We're talking GNOME 2.14, not sure if that'll make FC5.
> 
> But yes, when it is included, we can discuss these issues.

Ok, I was just hoping to get some of these thoughts going before it gets
to the point where these things cannot be changed or easily added.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From paolini at dmf.unicatt.it  Mon Jul 18 06:20:41 2005
From: paolini at dmf.unicatt.it (Maurizio Paolini)
Date: Mon, 18 Jul 2005 08:20:41 +0200
Subject: new kdeedu-3.4.1-... rpm
Message-ID: <20050718062041.GA13638@pascalp.dmf.bs.unicatt.it>

I have a rebuild version of the kdeedu-3.4.1 rpm (and the
corresponding "src.rpm") that solves the problem of 
kig-python-scripting.  It can be found in 
http://dmf.unicatt.it/~paolini/kig/fedora_core_4/

A am not able to contact the official packager (Ngo Than), and
that is the reason why I am posting here.
Is there any chance to have this package be officially
included in an FC4 update?

I previously had assurances by Ngo Than that python scripting
would have been enabled in the updates of FC4, but this
wasn't the case.

Thank you,
Maurizio Paolini



From rms at 1407.org  Mon Jul 18 06:59:23 2005
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 18 Jul 2005 07:59:23 +0100
Subject: gnome-user-share
In-Reply-To: <1121647580.2769.75.camel@yoda.loki.me>
References: <1121647580.2769.75.camel@yoda.loki.me>
Message-ID: <1121669963.2923.45.camel@roque>

On Sun, 2005-07-17 at 17:46 -0700, Jesse Keating wrote:
> So so far we have the introduction of gnome-user-share, which uses an
> http process dynamically bound to a port running as the user to share
> stuff in a ~/Public file to the world w/out auth. It sounds like

Is this folder mandatory, or is the path something you may choose?
It's just because it is unnecessary clutter imposed in the Desktop (when
Desktop == $HOME), and would probably be better suited at some other
place like Documents/Public or whatever.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050718/8efd0ea9/attachment.sig>

From jkeating at j2solutions.net  Mon Jul 18 07:12:30 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 18 Jul 2005 00:12:30 -0700
Subject: gnome-user-share
In-Reply-To: <1121669963.2923.45.camel@roque>
References: <1121647580.2769.75.camel@yoda.loki.me>
	<1121669963.2923.45.camel@roque>
Message-ID: <1121670750.2769.97.camel@yoda.loki.me>

On Mon, 2005-07-18 at 07:59 +0100, Rui Miguel Seabra wrote:
> Is this folder mandatory, or is the path something you may choose?
> It's just because it is unnecessary clutter imposed in the Desktop (when
> Desktop == $HOME), and would probably be better suited at some other
> place like Documents/Public or whatever.

Um... is the Desktop == $HOME in future releases?  I rather like
Desktop/ being it's own directory.  This follows suite from Apple OS X
and Windows so it is less confusing for new people.  Also I keep a lot
of stuff in the root of my home dir, I don't want these displayed on my
desktop.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From nicolas.mailhot at laposte.net  Mon Jul 18 08:09:38 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 18 Jul 2005 10:09:38 +0200 (CEST)
Subject: gnome-user-share
In-Reply-To: <1121647580.2769.75.camel@yoda.loki.me>
References: <1121647580.2769.75.camel@yoda.loki.me>
Message-ID: <54064.192.54.193.37.1121674178.squirrel@rousalka.dyndns.org>


On Lun 18 juillet 2005 02:46, Jesse Keating wrote:
> I've started a new thread because this discussion was going to get lost
> in the 200+ message thread-o-doom.
>
> So so far we have the introduction of gnome-user-share, which uses an
> http process dynamically bound to a port running as the user to share
> stuff in a ~/Public file to the world w/out auth. It sounds like
> gnome-user-auth will go into core.  The restrictions have been put
> forth:
>
> * Functionality is provided by a package and removed by a package, w/out
> core deps.
>
> * Functionality is controlled by a gconf entry which an admin can set to
> mandatory off (or just remove the package)
>
>
> Some ideas that have floated for this package include:
>
> * Functionality disabled until a file is placed in ~/Public prompting
> for a dialog box informing the user that the share is now active, with a
> link to more help in this.
>
> * Gnome-panel icon to show state of sharing with a timeout value to stop
> the share (configurable)
>
> * Integration with network-manager to enable/disable the share on
> specific networks
>
> Thoughts?

You also need some kind of monitoring to show who's the b*rd that's
connecting in the middle of a big download and sucking up all the
bandswidth (and a way to selectively kill connections).

Monitoring needs are inversely proportional to the ease with which you can
setup shares and make mistakes.

Regards,

-- 
Nicolas Mailhot



From P at draigBrady.com  Mon Jul 18 10:37:17 2005
From: P at draigBrady.com (P at draigBrady.com)
Date: Mon, 18 Jul 2005 11:37:17 +0100
Subject: ANN: anaconda yum migration testing
In-Reply-To: <1121488882.11796.6.camel@enki.eridu>
References: <1121488882.11796.6.camel@enki.eridu>
Message-ID: <42DB865D.7050909@draigBrady.com>

Paul Nasrat wrote:
> Over the next week as part of the work to try get anaconda installs
> using yum I'm going to switch over to yum by default:
> 
> * nfsiso installs will not be available

temporary I hope?
This is the handiest/most frequent install method I use.

-- 
P?draig Brady - http://www.pixelbeat.org
--



From pnasrat at redhat.com  Mon Jul 18 11:41:26 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Mon, 18 Jul 2005 07:41:26 -0400
Subject: ANN: anaconda yum migration testing
In-Reply-To: <42DB865D.7050909@draigBrady.com>
References: <1121488882.11796.6.camel@enki.eridu>
	<42DB865D.7050909@draigBrady.com>
Message-ID: <1121686887.3127.0.camel@enki.eridu>

On Mon, 2005-07-18 at 11:37 +0100, P at draigBrady.com wrote:
> Paul Nasrat wrote:
> > Over the next week as part of the work to try get anaconda installs
> > using yum I'm going to switch over to yum by default:
> > 
> > * nfsiso installs will not be available
> 
> temporary I hope?
> This is the handiest/most frequent install method I use.

Yes, we need the metadata support for this and CD based installs.  For
FC5 this will be back obviously.

Paul



From dwmw2 at infradead.org  Mon Jul 18 11:41:36 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Jul 2005 07:41:36 -0400
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <42DB1349.2080300@starhub.net.sg>
References: <42DB1349.2080300@starhub.net.sg>
Message-ID: <1121686897.4048.11.camel@localhost.localdomain>

On Mon, 2005-07-18 at 10:26 +0800, RChan wrote:
> While Pegasos II is not officially support as a PPC platform, some
> minor kernel tweaks would make it more friendly out-of-the-box for
> Pegasos II hackers. Would the maintainers kindly consider the
> following changes:

My Pegasos II arrived last week just before I left for the Kernel Summit
and OLS. Hopefully I'll sort out the kernel for it some time soon after
I get back -- thanks for the detailed pointers.

The boot thing is horrid; it'd be very much nicer to work out how to
make yaboot work instead of having to combine the objects. But we do
manage to merge the iSeries kernel and initrd, so I'm sure we could do
that if we really had to.

-- 
dwmw2



From dragoran at feuerpokemon.de  Mon Jul 18 12:03:33 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 18 Jul 2005 14:03:33 +0200
Subject: gnome-user-share
In-Reply-To: <1121670750.2769.97.camel@yoda.loki.me>
References: <1121647580.2769.75.camel@yoda.loki.me>	<1121669963.2923.45.camel@roque>
	<1121670750.2769.97.camel@yoda.loki.me>
Message-ID: <42DB9A95.9050904@feuerpokemon.de>

Jesse Keating wrote:

>On Mon, 2005-07-18 at 07:59 +0100, Rui Miguel Seabra wrote:
>  
>
>>Is this folder mandatory, or is the path something you may choose?
>>It's just because it is unnecessary clutter imposed in the Desktop (when
>>Desktop == $HOME), and would probably be better suited at some other
>>place like Documents/Public or whatever.
>>    
>>
>
>Um... is the Desktop == $HOME in future releases?  I rather like
>Desktop/ being it's own directory.  This follows suite from Apple OS X
>and Windows so it is less confusing for new people.  Also I keep a lot
>of stuff in the root of my home dir, I don't want these displayed on my
>desktop.
>
>  
>
no please leave it as it is now Desktop = $HOME would result in to many 
icons on the Desktop for many users.



From nicolas.mailhot at laposte.net  Mon Jul 18 12:20:14 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 18 Jul 2005 14:20:14 +0200 (CEST)
Subject: gnome-user-share
In-Reply-To: <42DB9A95.9050904@feuerpokemon.de>
References: <1121647580.2769.75.camel@yoda.loki.me>	<1121669963.2923.45.camel@roque>
	<1121670750.2769.97.camel@yoda.loki.me>
	<42DB9A95.9050904@feuerpokemon.de>
Message-ID: <33422.192.54.193.37.1121689214.squirrel@rousalka.dyndns.org>


On Lun 18 juillet 2005 14:03, dragoran wrote:
> Jesse Keating wrote:
>
>>On Mon, 2005-07-18 at 07:59 +0100, Rui Miguel Seabra wrote:
>>
>>
>>>Is this folder mandatory, or is the path something you may choose?
>>>It's just because it is unnecessary clutter imposed in the Desktop (when
>>>Desktop == $HOME), and would probably be better suited at some other
>>>place like Documents/Public or whatever.
>>>
>>>
>>
>>Um... is the Desktop == $HOME in future releases?  I rather like
>>Desktop/ being it's own directory.  This follows suite from Apple OS X
>>and Windows so it is less confusing for new people.  Also I keep a lot
>>of stuff in the root of my home dir, I don't want these displayed on my
>>desktop.
>>
>>
>>
> no please leave it as it is now Desktop = $HOME would result in to many
> icons on the Desktop for many users.

That's no reason to pollute the $HOME space for people that do use $HOME
as desktop today.

$HOME != desktop is nothing but an hack to avoid having to clean up all
the legacy apps that put random files here. It's not a license to
perpetuate the mess in new Gnome facilities. New apps $HOME usage should
set the example so $HOME can be reappropriated in the future.

-- 
Nicolas Mailhot



From vonbrand at inf.utfsm.cl  Mon Jul 18 01:44:38 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sun, 17 Jul 2005 21:44:38 -0400
Subject: No more right click terminal 
In-Reply-To: Message from Jeff Spaleta <jspaleta@gmail.com> of "Sun,
	17 Jul 2005 18:12:47 -0400."
	<604aa7910507171512204deb52@mail.gmail.com> 
Message-ID: <200507180144.j6I1icQC014541@laptop11.inf.utfsm.cl>

Jeff Spaleta <jspaleta at gmail.com> wrote:
> On 7/17/05, Nicolas Mailhot <Nicolas.Mailhot at laposte.net> wrote:
> > And unfortunately it's a bad distinction.
> > The real one is repetitive/non repetitive tasks.
> > Anything repetitive will always be better served by a rigid interface
> > like a terminal, not something as changing as the GUI.
> >
> > Just go look at any POS system - you'll never find even such a basic
> > thing as a mouse cursor. And the people using them have no CS doctorates
> > (at least most of them)

> Are you on crack?  There are many POS systems that have 'GUIS" and and
> driven by a touch screen interface instead of a "mouse" without
> exposing a terminal or a full keyboard.
> The existence of a "mouse cursor" is not the definition of a "GUI"  

> The WaWa convience store  sub sandwich ordering interface has no
> terminal.. no cmdline..it has no keyboard.. but it certaintly is a
> "graphical" "user" "interface".. 

Oh, come on. That is an /extremely/ limited task. Try doing the same if
there were hundreds of different sandwiches and options for each. Plus do
it for users sitting all day in front of the dang thing, not somebody
interacting with it a couple of minutes a month.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From rspchan at starhub.net.sg  Mon Jul 18 13:08:43 2005
From: rspchan at starhub.net.sg (Richard Chan)
Date: Mon, 18 Jul 2005 21:08:43 +0800
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <1121686897.4048.11.camel@localhost.localdomain>
References: <42DB1349.2080300@starhub.net.sg>
	<1121686897.4048.11.camel@localhost.localdomain>
Message-ID: <1121692123.4620.28.camel@localhost.localdomain>

Hi David,

Here's a bit of my experience with FC4:

0. I have totally rebuilt the FC4 kernel  2.6.12-1.1390_FC4 to get the
zImage.initrd.chrp. It is working well (though it was built using gcc
3.4 because that was all I had on my build machine - PPC64 RHEL AS 4 -
the gcc4 on RHEL AS 4 is too old to build the kernel because it ICEs
on the qlogic driver). In the next few days I'll try with gcc 4.0.1
with 2.6.12-1.1398_FC4.

1. Didn't have an installer so used one of the pre-installed Linuxen
to rsync an image over (from a PowerMac G4). With my new kernel the
whole thing works amazingly well. The chrp image can be booted by yaboot
and directly by OF.

vmlinux definitely isn't working (Sven Luther, responsible
for the Amiga partitioning patches to yaboot, attributes it both to
OF and yaboot. )

Quoth Sven Luther
>> Can someone explain the technical reason why yaboot doesn't boot
>>vmlinux
>> on Pegasos II?

>needs a new firmware upload, which is not quit ready yet.

>also yaboot is kinda brokenand uglmy, but this will be worked around,
>patience.

Also
>> What's with Pegasos II and vmlinux - any ideas?

>it's a size problem, and lack of free memory, and the fact that yaboot
>expect
>a not really standard conformant return from the claim call to allocate
>memory.

>btw, try mkvmlinuz :)

mkvmlinuz is a debianism - a kind of script to create vmlinuz but
requires object files from the kernel build (especially the stuff in
$BUILDTREE/arch/ppc/*) and the linker script
($SRCTREE/arch/ppc/boot/ld.script) to be kept around. I haven't got it
to work yet.


2. Userspace may need some help (or pointers) to get DRI to work because
of the unsupported (undetected?) AGP - I got DRI to work by forcing
BusType to "PCI" in  /etc/X11/xorg.conf; I noticed that YellowDog uses
Option "UseFBDev" - I wonder which is the "correct" way to do it?


But after all that, I'm delighted at how well the PPC FC4 userspace
works - really indistinguishable from my FC4 x86 boxen. The kernel, boot
loader, and anaconda, might be a bit fraught but at the moment it's
really fairly easy (apart from the whole kernel build) to get going
(assuming you can grab an image off a PowerMac). Incidentally, my same
kernel mod allows the Ubuntu 5.04 PowerPC LiveCD to run - which is quite
cool - and I used that to prep the harddisk and "ghost" FC4 onto my
second PegII machine.

Cheers
Richard 


On Mon, 2005-07-18 at 07:41 -0400, David Woodhouse wrote:
> On Mon, 2005-07-18 at 10:26 +0800, RChan wrote:
> > While Pegasos II is not officially support as a PPC platform, some
> > minor kernel tweaks would make it more friendly out-of-the-box for
> > Pegasos II hackers. Would the maintainers kindly consider the
> > following changes:
> 
> My Pegasos II arrived last week just before I left for the Kernel Summit
> and OLS. Hopefully I'll sort out the kernel for it some time soon after
> I get back -- thanks for the detailed pointers.
> 
> The boot thing is horrid; it'd be very much nicer to work out how to
> make yaboot work instead of having to combine the objects. But we do
> manage to merge the iSeries kernel and initrd, so I'm sure we could do
> that if we really had to.
> 
> -- 
> dwmw2
> 



From rdieter at math.unl.edu  Mon Jul 18 13:58:46 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 18 Jul 2005 08:58:46 -0500
Subject: new kdeedu-3.4.1-... rpm
In-Reply-To: <20050718062041.GA13638@pascalp.dmf.bs.unicatt.it>
References: <20050718062041.GA13638@pascalp.dmf.bs.unicatt.it>
Message-ID: <dbgcif$vtd$1@sea.gmane.org>

Maurizio Paolini wrote:
> I have a rebuild version of the kdeedu-3.4.1 rpm (and the
> corresponding "src.rpm") that solves the problem of 
> kig-python-scripting.  It can be found in 
> http://dmf.unicatt.it/~paolini/kig/fedora_core_4/
> 
> A am not able to contact the official packager (Ngo Than), and
> that is the reason why I am posting here.
> Is there any chance to have this package be officially
> included in an FC4 update?
> 
> I previously had assurances by Ngo Than that python scripting
> would have been enabled in the updates of FC4, but this
> wasn't the case.

Is this bugzilla'd?  If not, I'd recommend doing so.

-- Rex



From paolini at dmf.unicatt.it  Mon Jul 18 14:14:27 2005
From: paolini at dmf.unicatt.it (Maurizio Paolini)
Date: Mon, 18 Jul 2005 16:14:27 +0200
Subject: new kdeedu-3.4.1-... rpm
In-Reply-To: <dbgcif$vtd$1@sea.gmane.org>
References: <20050718062041.GA13638@pascalp.dmf.bs.unicatt.it>
	<dbgcif$vtd$1@sea.gmane.org>
Message-ID: <20050718141427.GE9081@pascalp.dmf.bs.unicatt.it>

On Mon, Jul 18, 2005 at 08:58:46AM -0500, Rex Dieter wrote:
> Maurizio Paolini wrote:
> >I have a rebuild version of the kdeedu-3.4.1 rpm (and the
> >corresponding "src.rpm") that solves the problem of 
> >kig-python-scripting.  It can be found in 
> >http://dmf.unicatt.it/~paolini/kig/fedora_core_4/
> >
> >A am not able to contact the official packager (Ngo Than), and
> >that is the reason why I am posting here.
> >Is there any chance to have this package be officially
> >included in an FC4 update?
> >
> >I previously had assurances by Ngo Than that python scripting
> >would have been enabled in the updates of FC4, but this
> >wasn't the case.
> 
> Is this bugzilla'd?  If not, I'd recommend doing so.

I already added some time ago an entry in bugzilla (#157961) related 
to this problem, but to no avail, unfortunately.  The problem seems that
Ngo Than somehow cannot be reached.

I agree that bugzilla is the right place for this kind of
problems, but it seems that it does not work as expected.

thanx,
Maurizio Paolini



From ph18 at cornell.edu  Mon Jul 18 15:33:26 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Mon, 18 Jul 2005 11:33:26 -0400
Subject: No more right click terminal
In-Reply-To: <1121462167.4036.32.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<1121274056.10565.15.camel@nexus.verbum.private>	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
Message-ID: <42DBCBC6.4020207@cornell.edu>

Colin Walters wrote:

>
>Completely, totally disagree.  Every time a non-developer/non-sysadmin
>has to use the terminal for something is a bug.
>  
>
    If that's the case,  you've got a lot of bugs to fix.

    I've been burnt so many times by bugs in Red Hat's GUI stuff that I 
just don't have time to waste with it.  I think of the guy (in a message 
last week on this list) who had NetworkManager blow out his resolv.conf 
settings...  Every time I hit "Ok" on one of those screens,  I'm afraid 
that it's going to lead to a disaster that's "Not Ok".

    All the time I see friends struggling to figure out how to do 
something in the GUI,  and I have them open up a command line and get 
the job quickly,  and correctly the first time,  even coaching them over 
the phone -- /etc/sysconfig is a Red Hat introduction that I like a 
great deal -- a little bit of time spent learning how to navigate there 
means you can configure RH machines easily,  X Windows or not.

    Maybe it's better now than it used to be,  but I'm set in my ways.  
If RH manages to ship GUI tools that work 99.99% of the time rather than 
80% of the time,  maybe a new generation of people will start using them.



From paolini at dmf.unicatt.it  Mon Jul 18 15:41:48 2005
From: paolini at dmf.unicatt.it (Maurizio Paolini)
Date: Mon, 18 Jul 2005 17:41:48 +0200
Subject: new kdeedu-3.4.1-... rpm
In-Reply-To: <dbgcif$vtd$1@sea.gmane.org>
References: <20050718062041.GA13638@pascalp.dmf.bs.unicatt.it>
	<dbgcif$vtd$1@sea.gmane.org>
Message-ID: <20050718154148.GB13371@pascalp.dmf.bs.unicatt.it>

On Mon, Jul 18, 2005 at 08:58:46AM -0500, Rex Dieter wrote:
> 
> Is this bugzilla'd?  If not, I'd recommend doing so.

Yes, it is, and I actually got answers from bugzilla 
shortly after my post in fedora-devel :-)

thanx to everyone,

Maurizio Paolini



From buildsys at redhat.com  Mon Jul 18 15:54:10 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 18 Jul 2005 11:54:10 -0400
Subject: rawhide report: 20050718 changes
Message-ID: <200507181554.j6IFsA0O001347@porkchop.devel.redhat.com>

 

 
Updated Packages:

kernel-2.6.12-1.1435_FC5
------------------------
* Sun Jul 17 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git4

system-config-bind-4.0.0-19_FC5
-------------------------------

Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	ppp - 2.4.2-7.ppc64 requires libpcap.so.0.8.3()(64bit)
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	firstboot - 1.3.43-1.noarch requires system-config-display
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.ppc64 requires libpcap.so.0.8.3()(64bit)
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.x86_64 requires libpcap.so.0.8.3()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-bcel
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-apache-regexp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.2-7.x86_64 requires libpcap.so.0.8.3()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	ppp - 2.4.2-7.ia64 requires libpcap.so.0.8.3()(64bit)
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	isdn4k-utils - 3.2-29.ia64 requires libpcap.so.0.8.3()(64bit)
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	rgmanager - 1.9.31-3.ia64 requires ccs
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5



Broken deps for ppc
----------------------------------------------------------
	ppp - 2.4.2-7.ppc requires libpcap.so.0.8.3
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	isdn4k-utils - 3.2-29.ppc requires libpcap.so.0.8.3
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-regexp
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-apache-bcel



Broken deps for s390
----------------------------------------------------------
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	ppp - 2.4.2-7.s390 requires libpcap.so.0.8.3
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0



Broken deps for s390x
----------------------------------------------------------
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	ppp - 2.4.2-7.s390 requires libpcap.so.0.8.3
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis
	jonas - 4.3.3-1jpp_5fc.noarch requires xerces-j2 >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires xml-commons-apis >= 0:1.0
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2
	ppp - 2.4.2-7.s390x requires libpcap.so.0.8.3()(64bit)
	jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10



Broken deps for i386
----------------------------------------------------------
	isdn4k-utils - 3.2-29.i386 requires libpcap.so.0.8.3
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-resolver
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-log4j
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-regexp
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-commons-logging
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jsch
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-apache-bcel
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.2-7.i386 requires libpcap.so.0.8.3
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5





From ph18 at cornell.edu  Mon Jul 18 15:54:43 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Mon, 18 Jul 2005 11:54:43 -0400
Subject: No more right click terminal
In-Reply-To: <1121464079.2946.3.camel@localhost.localdomain>
References: <1121143049.3521.16.camel@localhost.localdomain>	<1121245649.12224.28.camel@localhost.localdomain>	<1121248417.16074.19.camel@goose>	<1121274056.10565.15.camel@nexus.verbum.private>	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>	<1121462167.4036.32.camel@nexus.verbum.private>	<20050715211752.GE954722@hiwaay.net>	<1121462915.2946.1.camel@localhost.localdomain>	<20050715213359.GI954722@hiwaay.net>
	<1121464079.2946.3.camel@localhost.localdomain>
Message-ID: <42DBD0C3.3070508@cornell.edu>

Nicholas Miell wrote

>Well, no. Hosting servers would run WebDAV.
>  
>
    Ever tried it?

    Can you say "support call?"

    On paper WebDAV is great,  but every WebDAV installation I've run 
has had problems.

    Most of the windows clients,  including the Win XP shell and the 
latest version of Dreamweaver,  are real basket cases.  On top of that,  
if you've got enough people using WebDAV that you 'benefit' from the 
locking,  you'll regularly have somebody lock a file and then take off 
for patagonia and then I have to nuke all of the locks on that server 
because there's no (straightforward) way for me to clear just one lock 
as an adminstrator.



From michael.es.carney at sbcglobal.net  Mon Jul 18 15:30:06 2005
From: michael.es.carney at sbcglobal.net (Michael W. Carney)
Date: Mon, 18 Jul 2005 08:30:06 -0700
Subject: FC3: kernel-smp-2.6.12-1.1372_FC3 panics on boot
Message-ID: <dbgi0a$im4$1@sea.gmane.org>


insmod: error inserting /lib/aic7xxx.ko: unknown symbol in module
insmod: error inserting /lib/ext3.ko: unknown symbol in module

of course the root fs can't be mounted, and a panic immediately results.

details:

machine is a dell precision workstation 530n, with dual Xeon 2GHz processors

42> lspci
00:00.0 Host bridge: Intel Corp. 82860 860 (Wombat) Chipset Host Bridge
(MCH) (rev 04)
00:01.0 PCI bridge: Intel Corp. 82850 850 (Tehama) Chipset AGP Bridge (rev
04)
00:02.0 PCI bridge: Intel Corp. 82860 860 (Wombat) Chipset AGP Bridge (rev
04)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 04)
00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 04)
00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04)
00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 04)
00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio
(rev 04)
01:00.0 VGA compatible controller: nVidia Corporation NV11GL [Quadro2
MXR/EX] (rev b2)
02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03)
03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt
Controller (rev 01)
03:0c.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
04:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
78)
43>

I looked at a previous posting which suggested removing the 2.6.12-1.1372
kernel, moving /etc/sysconfig/hwconf and /etc/modprobe.conf off to the
side, and rerunning kudzu then reinstalling the kernel. This procedure
doesn't work.




From tibbs at math.uh.edu  Mon Jul 18 17:18:20 2005
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Mon, 18 Jul 2005 12:18:20 -0500
Subject: FC3: kernel-smp-2.6.12-1.1372_FC3 panics on boot
In-Reply-To: <dbgi0a$im4$1@sea.gmane.org> (Michael W. Carney's message of
	"Mon, 18 Jul 2005 08:30:06 -0700")
References: <dbgi0a$im4$1@sea.gmane.org>
Message-ID: <ufa8y04823n.fsf@epithumia.math.uh.edu>

>>>>> "MWC" == Michael W Carney <michael.es.carney at sbcglobal.net> writes:

MWC> insmod: error inserting /lib/aic7xxx.ko: unknown symbol in module
MWC> insmod: error inserting /lib/ext3.ko: unknown symbol in module

Many people see problems like this because the SMP kernel is broken.
Please check in bugzilla:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163407
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163437

There may be others, so try a search.

 - J<



From Axel.Thimm at ATrpms.net  Mon Jul 18 18:36:49 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Mon, 18 Jul 2005 20:36:49 +0200
Subject: Guaranteed upgrade paths in updates-testing?
Message-ID: <20050718183649.GL22981@neu.nirvana>

The rawhide policy is to not guarantee upgrade paths within rawhide
and/or the releases based on a rawhide snapshot.

The reason is that rawhide may try a newer package that may have to be
downgraded and one wants to avoid epoch inflation.

That's OK for rawhide, but what about "updates-testing"? Can we have
such a guarantee there?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050718/35bea896/attachment.sig>

From byte at aeon.com.my  Mon Jul 18 19:17:26 2005
From: byte at aeon.com.my (Colin Charles)
Date: Mon, 18 Jul 2005 15:17:26 -0400
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <1121692123.4620.28.camel@localhost.localdomain>
References: <42DB1349.2080300@starhub.net.sg>
	<1121686897.4048.11.camel@localhost.localdomain>
	<1121692123.4620.28.camel@localhost.localdomain>
Message-ID: <1121714246.3299.477.camel@potter.soho.bytebot.net>

On Mon, 2005-07-18 at 21:08 +0800, Richard Chan wrote:

> 1. Didn't have an installer so used one of the pre-installed Linuxen
> to rsync an image over (from a PowerMac G4). With my new kernel the
> whole thing works amazingly well. The chrp image can be booted by yaboot
> and directly by OF.

I've recently found out that YDL also doesn't have a working installer
(I was under the impression that they did, but didn't send it upstream).
They have *plans* to do that, but no plans on working about it openly
from what I gather, so we may be doing a duplication of work here
-- 
Colin Charles, http://www.bytebot.net/



From sundaram at redhat.com  Mon Jul 18 19:54:10 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 19 Jul 2005 01:24:10 +0530
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <1121714246.3299.477.camel@potter.soho.bytebot.net>
References: <42DB1349.2080300@starhub.net.sg>	<1121686897.4048.11.camel@localhost.localdomain>	<1121692123.4620.28.camel@localhost.localdomain>
	<1121714246.3299.477.camel@potter.soho.bytebot.net>
Message-ID: <42DC08E2.7090708@redhat.com>

Colin Charles wrote:

>On Mon, 2005-07-18 at 21:08 +0800, Richard Chan wrote:
>
>  
>
>>1. Didn't have an installer so used one of the pre-installed Linuxen
>>to rsync an image over (from a PowerMac G4). With my new kernel the
>>whole thing works amazingly well. The chrp image can be booted by yaboot
>>and directly by OF.
>>    
>>
>
>I've recently found out that YDL also doesn't have a working installer
>(I was under the impression that they did, but didn't send it upstream).
>They have *plans* to do that, but no plans on working about it openly
>from what I gather, so we may be doing a duplication of work here
>  
>
Do they have a cvs or anything to take a quick peek at whats going on 
out there

regards
Rahul



From byte at aeon.com.my  Mon Jul 18 21:41:55 2005
From: byte at aeon.com.my (Colin Charles)
Date: Mon, 18 Jul 2005 17:41:55 -0400
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <42DC08E2.7090708@redhat.com>
References: <42DB1349.2080300@starhub.net.sg>
	<1121686897.4048.11.camel@localhost.localdomain>
	<1121692123.4620.28.camel@localhost.localdomain>
	<1121714246.3299.477.camel@potter.soho.bytebot.net>
	<42DC08E2.7090708@redhat.com>
Message-ID: <1121722916.3299.499.camel@potter.soho.bytebot.net>

On Tue, 2005-07-19 at 01:24 +0530, Rahul Sundaram wrote:
> >I've recently found out that YDL also doesn't have a working
> installer
> >(I was under the impression that they did, but didn't send it
> upstream).
> >They have *plans* to do that, but no plans on working about it openly
> >from what I gather, so we may be doing a duplication of work here
> >  
> >
> Do they have a cvs or anything to take a quick peek at whats going on 
> out there

No, but they do release srpms iirc. Or get a ydl.net account (USD
$80/yr ?) and get early access (i.e. current) stuff
-- 
Colin Charles, http://www.bytebot.net/



From rspchan at starhub.net.sg  Tue Jul 19 01:00:47 2005
From: rspchan at starhub.net.sg (RChan)
Date: Tue, 19 Jul 2005 09:00:47 +0800
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <1121714246.3299.477.camel@potter.soho.bytebot.net>
References: <42DB1349.2080300@starhub.net.sg>
	<1121686897.4048.11.camel@localhost.localdomain>
	<1121692123.4620.28.camel@localhost.localdomain>
	<1121714246.3299.477.camel@potter.soho.bytebot.net>
Message-ID: <42DC50BF.7020508@starhub.net.sg>

Yes - their 1 CD Pegasos installer is basically enough to partition your 
hard disk and
untar a minimal YDL install - after that you are supposed to yum to get 
the rest.
But, hey, that's not necessarily a bad way to do it...

Colin Charles wrote:

>On Mon, 2005-07-18 at 21:08 +0800, Richard Chan wrote:
>
>  
>
>>1. Didn't have an installer so used one of the pre-installed Linuxen
>>to rsync an image over (from a PowerMac G4). With my new kernel the
>>whole thing works amazingly well. The chrp image can be booted by yaboot
>>and directly by OF.
>>    
>>
>
>I've recently found out that YDL also doesn't have a working installer
>(I was under the impression that they did, but didn't send it upstream).
>They have *plans* to do that, but no plans on working about it openly
>from what I gather, so we may be doing a duplication of work here
>  
>



From rspchan at starhub.net.sg  Tue Jul 19 02:45:33 2005
From: rspchan at starhub.net.sg (RChan)
Date: Tue, 19 Jul 2005 10:45:33 +0800
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <42DC50BF.7020508@starhub.net.sg>
References: <42DB1349.2080300@starhub.net.sg>
	<1121686897.4048.11.camel@localhost.localdomain>
	<1121692123.4620.28.camel@localhost.localdomain>
	<1121714246.3299.477.camel@potter.soho.bytebot.net>
	<42DC50BF.7020508@starhub.net.sg>
Message-ID: <42DC694D.3080104@starhub.net.sg>

Ouch just had a bad experience booting 2.6.12-1.1398_FC4 built by
gcc 4.0.1 for Pegasos II PPC arch.

After creating zImage.initrd.chrp I'm getting gunzip errors from the kernel:
(everything is fine with gcc 3.4.x BTW)

chrpboot starting: loaded at 0x00800000
initial ramdisk moving 0x3e390000 <- 0x009cd000 (1c61f3 bytes)
gunzipping (0x00010000 <- 0x00807ce8:0x009cc710)...inflate returned
-5 msg: <NULL>




RChan wrote:

> Yes - their 1 CD Pegasos installer is basically enough to partition 
> your hard disk and
> untar a minimal YDL install - after that you are supposed to yum to 
> get the rest.
> But, hey, that's not necessarily a bad way to do it...
>
> Colin Charles wrote:
>
>> On Mon, 2005-07-18 at 21:08 +0800, Richard Chan wrote:
>>
>>  
>>
>>> 1. Didn't have an installer so used one of the pre-installed Linuxen
>>> to rsync an image over (from a PowerMac G4). With my new kernel the
>>> whole thing works amazingly well. The chrp image can be booted by 
>>> yaboot
>>> and directly by OF.
>>>   
>>
>>
>> I've recently found out that YDL also doesn't have a working installer
>> (I was under the impression that they did, but didn't send it upstream).
>> They have *plans* to do that, but no plans on working about it openly
>> from what I gather, so we may be doing a duplication of work here
>>  
>>
>



From divij at innomedia.soft.net  Tue Jul 19 09:14:23 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Tue, 19 Jul 2005 14:44:23 +0530
Subject: nptl and signals -II
Message-ID: <1121764462.5655.6.camel@localhost.localdomain>

Hi,
    I want to know that with nptl support signals(asynchronous) can be
delivered to specific threads or not.If yes then how can it be if no
then why and if u have any link regarding nptl signals plz plz plz......
fwd me.

Thanks in Advance
Divij



From jakub at redhat.com  Tue Jul 19 09:15:44 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 19 Jul 2005 05:15:44 -0400
Subject: nptl and signals -II
In-Reply-To: <1121764462.5655.6.camel@localhost.localdomain>
References: <1121764462.5655.6.camel@localhost.localdomain>
Message-ID: <20050719091544.GO30077@devserv.devel.redhat.com>

On Tue, Jul 19, 2005 at 02:44:23PM +0530, divij bhatt wrote:
> Hi,
>     I want to know that with nptl support signals(asynchronous) can be
> delivered to specific threads or not.If yes then how can it be if no
> then why and if u have any link regarding nptl signals plz plz plz......
> fwd me.

See man 3p pthread_kill or
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_kill.html

	Jakub



From danfr at matrix.co.il  Tue Jul 19 09:15:00 2005
From: danfr at matrix.co.il (Dan Fruehauf)
Date: Tue, 19 Jul 2005 12:15:00 +0300
Subject: nptl and signals -II
In-Reply-To: <1121764462.5655.6.camel@localhost.localdomain>
References: <1121764462.5655.6.camel@localhost.localdomain>
Message-ID: <1121764500.4417.2.camel@isz>

Divij,
You should look at pthread_kill - it probably does what you want.
All you have to do is specify the thread id and the signal number.
AFAIK you can send it to threads only in the same process.

Cheers.

On Tue, 2005-07-19 at 14:44 +0530, divij bhatt wrote:
> Hi,
>     I want to know that with nptl support signals(asynchronous) can be
> delivered to specific threads or not.If yes then how can it be if no
> then why and if u have any link regarding nptl signals plz plz plz......
> fwd me.
> 
> Thanks in Advance
> Divij
> 



From buildsys at redhat.com  Tue Jul 19 11:38:18 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 19 Jul 2005 07:38:18 -0400
Subject: rawhide report: 20050719 changes
Message-ID: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>

 

 
Updated Packages:

ant-0:1.6.2-3jpp_12fc
---------------------
* Mon Jul 18 2005 Gary Benson <gbenson at redhat.com> 0:1.6.2-3jpp_12fc
- Built on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles subpackages).
- Remove the jmf subpackage since it wasn't being built anyway.

aspell-cs-50:0.51-3
-------------------

aspell-cy-50:0.50-4
-------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.3-4
- build with aspell-0.60.3
aspell-da-50:0.50-12
--------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-12
- build with aspell-0.60.3

aspell-de-50:0.50-11
--------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-11
- build with aspell-0.60.3

aspell-el-50:0.50-4
-------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.3-4
- build with aspell-0.60.3
aspell-en-50:6.0-1
------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:6.0-1
- update to aspell5-en-6.0
- build with aspell-0.60.3

aspell-es-50:0.50-12
--------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-12
- build with aspell-0.60.3

aspell-fo-50:0.51-4
-------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.51-4
- build with aspell-0.60.3
aspell-fr-50:0.50-9
-------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-9
- build with aspell-0.60.3

aspell-ga-50:0.50-4
-------------------
* Mon Jul 18 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.4-4
- build with aspell-0.60.3
aspell-gd-50:0.50-4
-------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.0-4
-  build with aspell-0.60.3
aspell-gl-50:0.50-4
-------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.0-4
- build with aspell-0.60.3
aspell-hr-50:0.51-4
-------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.51.0-4
- build with aspell-0.60.3
aspell-id-50:0.50.1-4
---------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.1-4
- build with aspell-0.60.3
aspell-is-50:0.51.1-2
---------------------

aspell-it-50:0.53-3
-------------------

aspell-nl-50:0.50-7
-------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-7
- build with aspell-0.60.3

aspell-no-50:0.50.1-9
---------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50.1-9
- build with aspell-0.60.3

aspell-pl-50:0.51-4
-------------------

aspell-pt-50:0.50-10
--------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-10
- build with aspell-0.60.3

aspell-ru-50:0.99f7-2
---------------------

aspell-sv-50:0.50-8
-------------------
* Tue Jul 19 2005 Ivana Varekova <varekova at redhat.com> 50:0.50-8
- build with aspell-0.60.3

audit-0.9.19-2
--------------
* Mon Jul 18 2005 Tomas Mraz <tmraz at redhat.com> 0.9.19-2
- make /usr/lib/libaudit.so point at the right file

cairo-0.5.2-1
-------------
* Mon Jul 18 2005 Kristian H??gsberg <krh at redhat.com> 0.5.2-1
- Update to cairo-0.5.2 and drop bitmap font patch.

cdrdao-1.2.0-1
--------------
* Mon Jul 18 2005 Harald Hoyer <harald at redhat.com> 1.2.0-1
- version 1.2.0

dbus-0.35.2-1
-------------
* Mon Jul 18 2005 John (J5) Palmieri <johnp at redhat.com> - 0.35.2-1
- Upgrade to dbus-0.35.2
- removed dbus-0.34-kill-babysitter.patch
- removed dbus-0.34-python-threadsync.patch
- removed dbus-0.23-selinux-avc-audit.patch
- added dbus-0.35.2-selinux-avc-audit.patch
- take out restarts on upgrade

diskdumputils-1.1.7-4
---------------------
* Mon Jul 18 2005 Akira Imamura <aimamura at redhat.com> 1.1.7-4
Updated source package to 1.1.7, which:
  - Enabled to configure diskdump with /proc/mounts.  BZ #155200
  - Multiple PT_LOAD segments support.  BZ #149753,154923

docbook-style-xsl-1.69.0-1
--------------------------
* Mon Jul 18 2005 Tim Waugh <twaugh at redhat.com> 1.69.0-1
- 1.69.0.

esound-1:0.2.36-1
-----------------
* Mon Jul 18 2005 John (J5) Palmieri <johnp at redhat.com> - 1:0.2.36-1
- Updated to 0.2.36
- removed esound-0.2.35-manpage.patch

fetchmail-6.2.5-10
------------------
* Mon Jul 18 2005 Karsten Hopp <karsten at redhat.de> 6.2.5-10
- Buildrequires gettext-devel for AM_GNU_GETTEXT macro

firefox-1.1-0.2.1.deerpark.alpha2
---------------------------------
* Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.1.deerpark.alpha2
- Rebuild

* Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.0.1.deerpark.alpha2
- Update to Deer Park Alpha 2
  - STILL TODO:
    - This build is not localized yet.
    - Theme issues not yet resolved.
    - Building on ppc platforms is busted, disable them for now.
    - Forward port all remaining patches.

* Sun Jul 17 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.4-6
- Avoid a crash on 64bit platforms
- Use system NSPR

foomatic-3.0.2-22
-----------------
* Mon Jul 18 2005 Tim Waugh <twaugh at redhat.com> 3.0.2-22
- Updated db to 20050718.

ghostscript-8.15-0.rc3.6
------------------------
* Mon Jul 18 2005 Tim Waugh <twaugh at redhat.com> 8.15-0.rc3.6
- Fixed split font configuration patch (bug #161187).

gimp-print-4.2.7-11
-------------------
* Mon Jul 18 2005 Tim Waugh <twaugh at redhat.com> 4.2.7-11
- Build requires libtiff-devel (bug #163511).

gnome-media-2.11.5-1
--------------------
* Mon Jul 18 2005 John (J5) Palmieri <johnp at redhat.com> 2.11.5-1
- Update to 2.11.5

gnome-python2-2.11.3-1
----------------------
* Mon Jul 18 2005 John (J5) Palmieri <johnp at redhat.com> - 2.11.3
- update to upstream 2.11.3

* Fri Mar 11 2005 John (J5) Palmieri <johnp at redhat.com> - 2.10.0
- update to 2.10.0
- add a Requires line for gnome-python2-gnomevfs

* Mon Mar 07 2005 Jeremy Katz <katzj at redhat.com> - 2.9.5-1
- update to 2.9.5

gtk2-2.7.3-1
------------
* Fri Jul 15 2005 Matthias Clasen <mclasen at redhat.com>
- Update to 2.7.3

iiimf-1:12.2-7
--------------
* Thu Jul 07 2005 Akira TAGOH <tagoh at redhat.com> - 1:12.2-7
- xiiimp-pango.patch: applied to show the glyphs on the status window
  and the candidate window with Pango. (#141723)
- the above patch also contains a fix to get the hotmenu working
  on even iiimx. (#162125)
- removed the unnecessary/not applied patches anymore:
  - im-sdk-12.1-x-xft-highlight.patch
  - xiiimp-xft-statusarea-147457.patch
  - xiiimp-xft.patch

* Mon Jun 27 2005 Akira TAGOH <tagoh at redhat.com>
- iiimd-init.d: fixed that service iiim status didn't work properly. (#161766)

iptables-1.3.2-1
----------------
* Mon Jul 18 2005 Thomas Woerner <twoerner at redhat.com> 1.3.2-1
- new version 1.3.2 with additional patch for the misplaced free_opts call
  from Marcus Sundberg

iputils-20020927-24
-------------------
* Mon Jul 18 2005 Radek Vokal <rvokal at redhat.com> 20020927-24
- fixed arping buffer overflow (#163383)

isdn4k-utils-3.2-30
-------------------
* Mon Jul 18 2005 Than Ngo <than at redhat.com> 3.2-30 
- rebuild to fix broken dependencies

kdbg-1:2.0.0-1
--------------
* Mon Jul 18 2005 Than Ngo <than at redhat.com> 1:2.0.0-1
- 2.0.0

kdeedu-3.4.1-2
--------------
* Mon Jul 18 2005 Than Ngo <than at redhat.com> 3.4.1-2
- enable python-scripting #157961

libsepol-1.7.5-1
----------------
* Mon Jul 18 2005 Dan Walsh <dwalsh at redhat.com> 1.7.5-1
- Upgrade to latest from NSA
	* Merged debug support, policydb conversion functions from Ivan Gyurdiev (Red Hat).
	* Removed genpolbools and genpolusers utilities.
	* Merged hierarchy check fix from Joshua Brindle (Tresys).

metacity-2.11.0-3
-----------------
* Mon Jul 18 2005 Matthias Clasen <mclasen at redhat.com> 2.11.0-3
- fix xcursor detection

pam-0.80-2
----------
* Mon Jul 18 2005 Tomas Mraz <tmraz at redhat.com> 0.80-2
- fixed module tests so the pam doesn't require itself to build (#163502)
- added buildprereq for building the documentation (#163503)
- relaxed permissions of binaries (u+w)

parted-1.6.23-2
---------------
* Mon Jul 18 2005 Chris Lumens <clumens at redhat.com> 1.6.23-2
- Add buildreq for texinfo.

ppp-2.4.3-1
-----------
* Mon Jul 18 2005 Thomas Woerner <twoerner at redhat.com> 2.4.3-1
- new version 2.4.3
  - updated patches: make, lib64, dontwriteetc, fix, fix64, no_strip,
    radiusplugin
  - dropped patches: bpf, signal, pcap, pppoatm, pkgcheck

pygtk2-2.7.0-1
--------------
* Mon Jul 18 2005 John (J5) Palmieri <johnp at redhat.com> - 2.7.0-1
- Update to upstream 2.7.0

radvd-0.8-1.FC5
---------------
* Mon Jul 18 2005 Jason Vas Dias <jvdias at redhat.com> 0.8-1.FC5
- Upgrade to upstream version 0.8

* Fri Jul 08 2005 Pekka Savola <pekkas at netcore.fi> 0.8-1
- 0.8.
- Ship the example config file as %doc (Red Hat's #159005)

tanukiwrapper-0:3.1.1-4jpp_2fc
------------------------------
* Mon Jul 18 2005 Gary Benson <gbenson at redhat.com> - 0:3.1.1-4jpp_2fc
- Build on ia64, ppc64, s390 and s390x.

thunderbird-0:1.0.6-0.1.fc5
---------------------------
* Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com> 1.0.6-0.1.fc5
- 1.0.6 Release Candidate

xerces-j2-0:2.6.2-5jpp_2fc
--------------------------
* Mon Jul 18 2005 Gary Benson <gbenson at redhat.com> 0:2.6.2-5jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles samples).

xfig-3.2.4-12
-------------
* Mon Jul 18 2005 Than Ngo <than at redhat.com> 3.2.4-12
- fix another buffer overflow #163413

xml-commons-0:1.0-0.b2.7jpp_3fc
-------------------------------
* Fri Jul 15 2005 Gary Benson <gbenson at redhat.com> - 0:1.0-0.b2.7jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles the which jar).

* Wed Jun 15 2005 Gary Benson <gbenson at redhat.com> - 0:1.0-0.b2.7jpp_2fc
- Remove all prebuilt stuff from the tarball.

* Thu May 26 2005 Gary Benson <gbenson at redhat.com> - 0:1.0-0.b2.7jpp_1fc
- Upgrade to 1.0-0.b2.7jpp.
- Remove now-unnecessary workaround for #130162.
- Rearrange how BC-compiled stuff is built and installed.

Broken deps for i386
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.3-1.i386 requires /usr/local/bin/expect
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	ppp - 2.4.3-1.x86_64 requires /usr/local/bin/expect
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	ppp - 2.4.3-1.ia64 requires /usr/local/bin/expect
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	rgmanager - 1.9.31-3.ia64 requires ccs
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16



Broken deps for ppc
----------------------------------------------------------
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-1.ppc requires /usr/local/bin/expect
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1



Broken deps for ppc64
----------------------------------------------------------
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-1.ppc64 requires /usr/local/bin/expect
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	firstboot - 1.3.43-1.noarch requires system-config-display
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	ppp - 2.4.3-1.s390 requires /usr/local/bin/expect
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4



Broken deps for s390x
----------------------------------------------------------
	selinux-policy-strict - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1
	selinux-policy-strict-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0
	jonas - 4.3.3-1jpp_5fc.noarch requires servletapi5
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-el
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-digester >= 0:1.6
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-collections >= 0:3.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jakarta-commons-modeler >= 0:1.1
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	velocity - 1.4-3jpp_1fc.noarch requires servletapi5
	velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections
	hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	jorm - 2.4.3-1jpp_2fc.noarch requires jakarta-commons-collections
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections
	joram - 4.1.5-1jpp_2fc.noarch requires jmxri
	ppp - 2.4.3-1.s390x requires /usr/local/bin/expect
	castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1
	jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	avalon-logkit - 1.2-3jpp_1fc.noarch requires servletapi5
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21





From thomas at apestaart.org  Tue Jul 19 12:04:50 2005
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Tue, 19 Jul 2005 14:04:50 +0200
Subject: location of developer documentation
Message-ID: <1121774690.13104.2.camel@thomas.amantes>

Hi everyone,

most packages in Fedora install their development documentation
in /usr/share/doc/%{name}-devel-%{version}

I find this really annoying because every time a package gets upgraded
it breaks the bookmarks I make for documentation for no good reason.

Also, most upstream tarballs that actually install documentation by
themselves install it in $(datadir)/doc/$(name).

Is there a good reason for Fedora to override this usual location and
install developer docs in this versioned location ? What do people
think ?

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
See how I vigorously don't care
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From janina at rednote.net  Tue Jul 19 12:59:28 2005
From: janina at rednote.net (Janina Sajka)
Date: Tue, 19 Jul 2005 08:59:28 -0400
Subject: OT: Need quick tips re VNC &/or WebDAV
Message-ID: <20050719125928.GA11920@rednote.net>

-
-------------- next part --------------
-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

From dcbw at redhat.com  Tue Jul 19 13:24:46 2005
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 19 Jul 2005 09:24:46 -0400
Subject: location of developer documentation
In-Reply-To: <1121774690.13104.2.camel@thomas.amantes>
References: <1121774690.13104.2.camel@thomas.amantes>
Message-ID: <1121779486.1094.1.camel@dcbw.boston.redhat.com>

On Tue, 2005-07-19 at 14:04 +0200, Thomas Vander Stichele wrote:
> Hi everyone,
> 
> most packages in Fedora install their development documentation
> in /usr/share/doc/%{name}-devel-%{version}
> 
> I find this really annoying because every time a package gets upgraded
> it breaks the bookmarks I make for documentation for no good reason.
> 
> Also, most upstream tarballs that actually install documentation by
> themselves install it in $(datadir)/doc/$(name).
> 
> Is there a good reason for Fedora to override this usual location and
> install developer docs in this versioned location ? What do people
> think ?

Well, for things like db4, openssl, libcurl, gcc/compat-gcc, and
anything else you're likely to have more than one version of due to
compatibility requirements, its the best thing to do...  However, that
is maybe 10% of the total package count.

Dan



From pmatilai at laiskiainen.org  Tue Jul 19 13:37:34 2005
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 19 Jul 2005 16:37:34 +0300
Subject: location of developer documentation
In-Reply-To: <1121779486.1094.1.camel@dcbw.boston.redhat.com>
References: <1121774690.13104.2.camel@thomas.amantes>
	<1121779486.1094.1.camel@dcbw.boston.redhat.com>
Message-ID: <1121780254.7259.25.camel@weasel.turre.laiskiainen.org>

On Tue, 2005-07-19 at 09:24 -0400, Dan Williams wrote:
> On Tue, 2005-07-19 at 14:04 +0200, Thomas Vander Stichele wrote:
> > Hi everyone,
> > 
> > most packages in Fedora install their development documentation
> > in /usr/share/doc/%{name}-devel-%{version}
> > 
> > I find this really annoying because every time a package gets upgraded
> > it breaks the bookmarks I make for documentation for no good reason.
> > 
> > Also, most upstream tarballs that actually install documentation by
> > themselves install it in $(datadir)/doc/$(name).
> > 
> > Is there a good reason for Fedora to override this usual location and
> > install developer docs in this versioned location ? What do people
> > think ?
> 
> Well, for things like db4, openssl, libcurl, gcc/compat-gcc, and
> anything else you're likely to have more than one version of due to
> compatibility requirements, its the best thing to do...  However, that
> is maybe 10% of the total package count.

But in those cases the package name is different, so you'd have
/usr/share/doc/compat-gcc vs /usr/share/doc/gcc etc.

	- Panu -



From johnp at redhat.com  Tue Jul 19 13:53:11 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Tue, 19 Jul 2005 09:53:11 -0400
Subject: Investigating moving FC4 to D-Bus 0.35.2
Message-ID: <1121781191.3101.28.camel@remedyz.boston.redhat.com>

Hey guys,

In the intrest of getting API's out that more reflect what we will see
in D-Bus 1.0 I am toying with the idea of upgrading FC4 to the same
version in Rawhide.  This does not effect the lowlevel D-Bus libraries
except for fixing a couple of bugs.  What this does is give a more
usable GLib and Python bindings.

What this also does is break apps using those bindings.  GLib is a
pretty big change but then again this is the first release we thought
was good enough for mass consumption.  

Python itself is changed in a number of ways but mostly when creating a
service.  Clients on the bus who just fire off blocking messages should
have no changes needed.  Clients who still need a mainloop will simply
have to import dbus.glib.

With FC5 a ways off I think it is more important to get wide use of
these API's as they will most likely be than to keep compatability with
the 0.33 bindings.  I'm not promising API's won't change but we are now
in the mode where we are trying to keep them relitivly the same.

The purpose of this mail is to find out if there are any third party
apps that use the GLib or Python bindings that are packaged for or with
FC4 and if those developers would object to this upgrade.  The real
question is would you like the pain now or later? :-) I'll put a tarball
in testing sometime this week.

I say rip the bandade, but that is just me.  The GLib bindings shouldn't
have seen much use as of yet and the Python bindings are mostly used for
clients of which requires a one or twoline change when using a mainloop.
I'm not aware of any production code that uses the Python bindings as a
server.  Plus with the new bindings the tutorials of fd.o
(http://dbus.freedesktop.org/doc/dbus-tutorial.html) will actually match
what is in FC-4.

Thanks,
-- 
John (J5) Palmieri <johnp at redhat.com>



From jspaleta at gmail.com  Tue Jul 19 14:25:07 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 19 Jul 2005 10:25:07 -0400
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
Message-ID: <604aa791050719072510d52df@mail.gmail.com>

On 7/19/05, John (J5) Palmieri <johnp at redhat.com> wrote:
> The purpose of this mail is to find out if there are any third party
> apps that use the GLib or Python bindings that are packaged for or with
> FC4 and if those developers would object to this upgrade.  The real
> question is would you like the pain now or later? :-) I'll put a tarball
> in testing sometime this week.

Just to get a quick idea a did some runs of repoquery on my fc4 system
repoquery --whatrequires dbus-python
repoquery --whatrequires dbus_bindings.so
repoquery --whatrequires dbus-glib
shows nothing in Extras or Livna that require any of these items.

but....
repoquery --whatrequires libdbus-glib-1.so.1
however shows some items from Extras:
screem - 0.14.1-1.fc4.i386
liferea - 0.9.3-1.fc4.i386
gossip - 0.8-5.fc4.i386

Everything else i see in the output are Core apps which I'm sure you
are aware of.

-jef



From pnasrat at redhat.com  Tue Jul 19 14:38:04 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Tue, 19 Jul 2005 10:38:04 -0400
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <604aa791050719072510d52df@mail.gmail.com>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
	<604aa791050719072510d52df@mail.gmail.com>
Message-ID: <1121783885.3149.18.camel@enki.eridu>

On Tue, 2005-07-19 at 10:25 -0400, Jeff Spaleta wrote:
> On 7/19/05, John (J5) Palmieri <johnp at redhat.com> wrote:
> > The purpose of this mail is to find out if there are any third party
> > apps that use the GLib or Python bindings that are packaged for or with
> > FC4 and if those developers would object to this upgrade.  The real
> > question is would you like the pain now or later? :-) I'll put a tarball
> > in testing sometime this week.
> 
> Just to get a quick idea a did some runs of repoquery on my fc4 system
> repoquery --whatrequires dbus-python
> repoquery --whatrequires dbus_bindings.so
> repoquery --whatrequires dbus-glib
> shows nothing in Extras or Livna that require any of these items.
> 
> but....
> repoquery --whatrequires libdbus-glib-1.so.1
> however shows some items from Extras:
> screem - 0.14.1-1.fc4.i386
> liferea - 0.9.3-1.fc4.i386
> gossip - 0.8-5.fc4.i386

yum-utils tip of the day - combine the above into a single query:

repoquery --repoid development --repoid extras-development --alldeps
--whatrequires dbus dbus-python | sort

Paul



From johnp at redhat.com  Tue Jul 19 14:40:23 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Tue, 19 Jul 2005 10:40:23 -0400
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <604aa791050719072510d52df@mail.gmail.com>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
	<604aa791050719072510d52df@mail.gmail.com>
Message-ID: <1121784023.3101.36.camel@remedyz.boston.redhat.com>

On Tue, 2005-07-19 at 10:25 -0400, Jeff Spaleta wrote:
> On 7/19/05, John (J5) Palmieri <johnp at redhat.com> wrote:
> > The purpose of this mail is to find out if there are any third party
> > apps that use the GLib or Python bindings that are packaged for or with
> > FC4 and if those developers would object to this upgrade.  The real
> > question is would you like the pain now or later? :-) I'll put a tarball
> > in testing sometime this week.
> 
> Just to get a quick idea a did some runs of repoquery on my fc4 system
> repoquery --whatrequires dbus-python
> repoquery --whatrequires dbus_bindings.so
> repoquery --whatrequires dbus-glib
> shows nothing in Extras or Livna that require any of these items.
> 
> but....
> repoquery --whatrequires libdbus-glib-1.so.1
> however shows some items from Extras:
> screem - 0.14.1-1.fc4.i386
> liferea - 0.9.3-1.fc4.i386
> gossip - 0.8-5.fc4.i386
> 
> Everything else i see in the output are Core apps which I'm sure you
> are aware of.

Searching for ibdbus-glib-1.so.1 doesn't show the whole picture because
most things will use the glib mainloop which has not changed API.
 
-- 
John (J5) Palmieri <johnp at redhat.com>



From jspaleta at gmail.com  Tue Jul 19 15:03:01 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 19 Jul 2005 11:03:01 -0400
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <1121783885.3149.18.camel@enki.eridu>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
	<604aa791050719072510d52df@mail.gmail.com>
	<1121783885.3149.18.camel@enki.eridu>
Message-ID: <604aa79105071908033b8ea166@mail.gmail.com>

On 7/19/05, Paul Nasrat <pnasrat at redhat.com> wrote:
> yum-utils tip of the day - combine the above into a single query:

can you also show me how to get the repoid added to the output,
--location isn't doing what i would naive expect, and I'd like to be
able to see whch repo a package is from instantly.
-jef



From hughsient at gmail.com  Tue Jul 19 15:11:21 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 19 Jul 2005 16:11:21 +0100
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <1121784023.3101.36.camel@remedyz.boston.redhat.com>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
	<604aa791050719072510d52df@mail.gmail.com>
	<1121784023.3101.36.camel@remedyz.boston.redhat.com>
Message-ID: <15e53e1805071908112dd66c96@mail.gmail.com>

On 7/19/05, John (J5) Palmieri <johnp at redhat.com> wrote:
> On Tue, 2005-07-19 at 10:25 -0400, Jeff Spaleta wrote:
> > On 7/19/05, John (J5) Palmieri <johnp at redhat.com> wrote:
> > > The purpose of this mail is to find out if there are any third party
> > > apps that use the GLib or Python bindings that are packaged for or with
> > > FC4 and if those developers would object to this upgrade.  The real
> > > question is would you like the pain now or later? :-) I'll put a tarball
> > > in testing sometime this week.

I've spent all morning converting GNOME Power Manager to use the new
GLIB api of rawhide's  0.35.2...

I can't think why you wouldn't want to break API, nobody said DBUS was stable.

Richard.



From pmatilai at laiskiainen.org  Tue Jul 19 15:23:46 2005
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 19 Jul 2005 08:23:46 -0700 (PDT)
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <604aa79105071908033b8ea166@mail.gmail.com>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
	<604aa791050719072510d52df@mail.gmail.com>
	<1121783885.3149.18.camel@enki.eridu>
	<604aa79105071908033b8ea166@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0507190819430.27862@gotcha.dreamhost.com>

On Tue, 19 Jul 2005, Jeff Spaleta wrote:

> On 7/19/05, Paul Nasrat <pnasrat at redhat.com> wrote:
>> yum-utils tip of the day - combine the above into a single query:
>
> can you also show me how to get the repoid added to the output,
> --location isn't doing what i would naive expect, and I'd like to be
> able to see whch repo a package is from instantly.

Add --qf "%{name} %{repoid}" or such to the query options.

Oh and I've been pondering about making --alldeps the default mode of 
--whatrequires queries since that's what people actually expect to see, I 
think?

 	- Panu -



From pnasrat at redhat.com  Tue Jul 19 15:25:13 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Tue, 19 Jul 2005 11:25:13 -0400
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <604aa79105071908033b8ea166@mail.gmail.com>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>
	<604aa791050719072510d52df@mail.gmail.com>
	<1121783885.3149.18.camel@enki.eridu>
	<604aa79105071908033b8ea166@mail.gmail.com>
Message-ID: <1121786714.3149.23.camel@enki.eridu>

On Tue, 2005-07-19 at 11:03 -0400, Jeff Spaleta wrote:
> On 7/19/05, Paul Nasrat <pnasrat at redhat.com> wrote:
> > yum-utils tip of the day - combine the above into a single query:
> 
> can you also show me how to get the repoid added to the output,
> --location isn't doing what i would naive expect, and I'd like to be
> able to see whch repo a package is from instantly.

You'll need yum-utils HEAD repoquery

python repoquery.py  --queryformat '%{repoid} %{name}' --whatrequires
dbus

:)

Paul




From seandarcy2 at gmail.com  Tue Jul 19 16:38:29 2005
From: seandarcy2 at gmail.com (sean)
Date: Tue, 19 Jul 2005 12:38:29 -0400
Subject: rawhide report: 20050719 changes
In-Reply-To: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
References: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
Message-ID: <dbjaa5$5sq$1@sea.gmane.org>

Build System wrote:
>  
> 
>  
> Updated Packages:
> 
[.......]
> 
> ppp-2.4.3-1
> -----------
> * Mon Jul 18 2005 Thomas Woerner <twoerner at redhat.com> 2.4.3-1
> - new version 2.4.3
>   - updated patches: make, lib64, dontwriteetc, fix, fix64, no_strip,
>     radiusplugin
>   - dropped patches: bpf, signal, pcap, pppoatm, pkgcheck
> 


--> Populating transaction set with selected packages. 
Please wait.
---> Package libpcap.x86_64 14:0.9.1-1 set to be updated
---> Package ethereal.x86_64 0:0.10.11-4 set to be updated
---> Package ppp.x86_64 0:2.4.3-1 set to be updated
---> Package libpcap.i386 14:0.9.1-1 set to be updated
--> Running transaction check
--> Processing Dependency: /usr/local/bin/expect for 
package: ppp
--> Finished Dependency Resolution
Error: Missing Dependency: /usr/local/bin/expect is needed 
by package ppp

sean



From fedora at camperquake.de  Tue Jul 19 16:49:23 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 19 Jul 2005 18:49:23 +0200
Subject: rawhide report: 20050719 changes
In-Reply-To: <dbjaa5$5sq$1@sea.gmane.org>
References: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
	<dbjaa5$5sq$1@sea.gmane.org>
Message-ID: <20050719184923.6aa9acca@nausicaa.camperquake.de>

Hi.

sean <seandarcy2 at gmail.com> wrote:

> Error: Missing Dependency: /usr/local/bin/expect is needed 
> by package ppp

Huh?



From cmadams at hiwaay.net  Tue Jul 19 19:54:09 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 19 Jul 2005 14:54:09 -0500
Subject: rawhide report: 20050719 changes
In-Reply-To: <20050719184923.6aa9acca@nausicaa.camperquake.de>
References: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
	<dbjaa5$5sq$1@sea.gmane.org>
	<20050719184923.6aa9acca@nausicaa.camperquake.de>
Message-ID: <20050719195409.GE1150842@hiwaay.net>

Once upon a time, Ralf Ertzinger <fedora at camperquake.de> said:
> sean <seandarcy2 at gmail.com> wrote:
> > Error: Missing Dependency: /usr/local/bin/expect is needed 
> > by package ppp
> 
> Huh?

A script under the install documentation starts with
"#!/usr/local/bin/expect -f".

Another good reason to "find doc -type f | xargs chmod -x".
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From ivazquez at ivazquez.net  Tue Jul 19 20:14:47 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 19 Jul 2005 16:14:47 -0400
Subject: rawhide report: 20050719 changes
In-Reply-To: <20050719195409.GE1150842@hiwaay.net>
References: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
	<dbjaa5$5sq$1@sea.gmane.org>
	<20050719184923.6aa9acca@nausicaa.camperquake.de>
	<20050719195409.GE1150842@hiwaay.net>
Message-ID: <1121804088.28256.10.camel@ignacio.lan>

On Tue, 2005-07-19 at 14:54 -0500, Chris Adams wrote:
> Once upon a time, Ralf Ertzinger <fedora at camperquake.de> said:
> > sean <seandarcy2 at gmail.com> wrote:
> > > Error: Missing Dependency: /usr/local/bin/expect is needed 
> > > by package ppp
> > 
> > Huh?
> 
> A script under the install documentation starts with
> "#!/usr/local/bin/expect -f".
> 
> Another good reason to "find doc -type f | xargs chmod -x".

Or have 'find $RPM_BUILD_ROOT%{_defaultdocdir} -type f | ...' at the end
of %install.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050719/2d2c3b16/attachment.sig>

From notting at redhat.com  Wed Jul 20 01:12:53 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 19 Jul 2005 21:12:53 -0400
Subject: yet more udev/hotplug changes
Message-ID: <20050720011253.GA14101@nostromo.devel.redhat.com>

Beginning tomorrow, hotplug events will now be handled directly by udev
for the:

- firmware
- scsi
- ieee1394

subsystems.

The only hotplug agents left will be input (because the kernel isn't fixed
yet) and net (because that's, well, different).

Removed but not replaced were the dasd/tape s390 agents; these just created
additional device symlinks for compatibility with really really old devfs
installations; it's probably time for this compatiblity to be removed.

Bill



From symbiont at berlios.de  Wed Jul 20 03:06:42 2005
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 20 Jul 2005 11:06:42 +0800
Subject: Ext-3 Commit I/O Error in 1398
Message-ID: <200507201106.42982.symbiont@berlios.de>

Hey:

Just got a commit i/o error for ext-3 in kernel-2.6.12-1.1398_FC4.  
Bunch of my files went wack-o and directory inodes became symlinks 
to ??.  Couldn't shutdown.  Init said I/O error.

Reverted back to 1390, recovery worked and files/dirs back to normal. I 
couldn't find any detailed logs and the kernel didn't panic.  So, it 
maybe a badblock on my HDD that it hit or something's screwed in the 
ext3 driver in 1398.

I'm not a kernel expert, but will be willing to run any diags on it to 
see if it happens again.  I've noticed that CONFIG_JBD_DEBUG is not 
set, so, i guess i'd have to recompile...

Anyway, has anyone else run into problems?

thx,
-- 
-jeff



From alexl at users.sourceforge.net  Wed Jul 20 05:42:04 2005
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Tue, 19 Jul 2005 22:42:04 -0700
Subject: Java Runtime Environment plugin for Firefox
In-Reply-To: <42DD87F4.80208@the-spa.com> (Jon Roland's message of "Tue,
	19 Jul 2005 18:08:36 -0500")
References: <42DD4D02.1050805@the-spa.com> <42DD85DC.8060203@wireless.org.au>
	<42DD87F4.80208@the-spa.com>
Message-ID: <s4oe8y824z.fsf@allele2.biol.berkeley.edu>

>>>>> "JR" == Jon Roland  writes:

JR> Jason Hecker wrote:
>> Build your own RPMs using the www.jpackage.org spec files and
>> downloading the JSE from Sun.  It's a bit of a PItA (and an
>> impediment to a fluid Linux experience) but it works well and the
>> Mozilla/Firefox plugin Java runs without a hassle (though it's
>> hidden deep in a convoluted directory tree).

JR> Thanks, but I don't know how to build an rpm from a spec file yet,
JR> and I'd rather not have to learn how right now. Surely someone has
JR> done this and made an easy solution available for those of us who
JR> just want things to work.

The instructions on http://www.jpackage.org/rebuilding.php are
step-by-step, and don't require you to know much about spec files,
just how to run a few commands from the command line.  It looks a bit
scary, but really it's actually very simple and the instructions don't
require you to learn about the ins-and-out of RPM packaging.

Until Sun provide either less brain-dead generic and/or
Fedora-specific RPMS, unfortunately this *is* the easiest (legal) way
to install Java in a nice Fedora-compliant way.   

Third-party packagers which want to be 100% above board (including
jpackage, freshrpms etc.) can't legally redistribute the RPM and
include the Sun binaries in their packages because the user needs to
download the binaries and agree to the EULA etc.  

AFAIK jpackage *would* provide straight binary RPMS this way, because
it would "just work" if they could be sure it was 100% legit, it's not
that they prefer it this way.  So in answer to your question, somebody
has "done this", but they can't legally redistribute those packaged
RPMs.

Having said that, it might be useful if jpackage could supply a script
that did the heavy lifting, and leaving just the download itself to
the user, but that should be brought up with the jpackage people.

Cheers,
Alex



From alexl at users.sourceforge.net  Wed Jul 20 05:50:45 2005
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Tue, 19 Jul 2005 22:50:45 -0700
Subject: Java Runtime Environment plugin for Firefox
In-Reply-To: <s4oe8y824z.fsf@allele2.biol.berkeley.edu> (Alex Lancaster's
	message of "Tue, 19 Jul 2005 22:42:04 -0700")
References: <42DD4D02.1050805@the-spa.com> <42DD85DC.8060203@wireless.org.au>
	<42DD87F4.80208@the-spa.com>
	<s4oe8y824z.fsf@allele2.biol.berkeley.edu>
Message-ID: <or4qaq81qi.fsf@allele2.biol.berkeley.edu>

Wrong list (sometimes happens when reading mailing lists via GMANE).

Apologies for the noise.

Alex



From seandarcy2 at gmail.com  Wed Jul 20 09:21:50 2005
From: seandarcy2 at gmail.com (sean)
Date: Wed, 20 Jul 2005 05:21:50 -0400
Subject: anybody have firefox-1.1-0.2.1.deerpark.alpha2 working?
Message-ID: <dbl53e$k2c$1@sea.gmane.org>

It doesn't start at all for me.

I also tried:

  ./firefox-bin
./firefox-bin: error while loading shared libraries: 
libmozjs.so: cannot open shared object file: No such file or 
directory

which of course is in the same directory - 
/usr/lib64/firefox-1.1 - but that's without all the script 
variables.

sean



From dragoran at feuerpokemon.de  Wed Jul 20 09:24:48 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 20 Jul 2005 11:24:48 +0200
Subject: Investigating moving FC4 to D-Bus 0.35.2
In-Reply-To: <1121786714.3149.23.camel@enki.eridu>
References: <1121781191.3101.28.camel@remedyz.boston.redhat.com>	<604aa791050719072510d52df@mail.gmail.com>	<1121783885.3149.18.camel@enki.eridu>	<604aa79105071908033b8ea166@mail.gmail.com>
	<1121786714.3149.23.camel@enki.eridu>
Message-ID: <42DE1860.7090900@feuerpokemon.de>

Paul Nasrat wrote:

>On Tue, 2005-07-19 at 11:03 -0400, Jeff Spaleta wrote:
>  
>
>>On 7/19/05, Paul Nasrat <pnasrat at redhat.com> wrote:
>>    
>>
>>>yum-utils tip of the day - combine the above into a single query:
>>>      
>>>
>>can you also show me how to get the repoid added to the output,
>>--location isn't doing what i would naive expect, and I'd like to be
>>able to see whch repo a package is from instantly.
>>    
>>
>
>You'll need yum-utils HEAD repoquery
>
>python repoquery.py  --queryformat '%{repoid} %{name}' --whatrequires
>dbus
>
>:)
>
>Paul
>
>
>  
>
just a question:
what has changed in dbus 0.35.2 (not only the api changes)?



From arjanv at redhat.com  Wed Jul 20 10:04:30 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 20 Jul 2005 06:04:30 -0400
Subject: yet more udev/hotplug changes
In-Reply-To: <20050720011253.GA14101@nostromo.devel.redhat.com>
References: <20050720011253.GA14101@nostromo.devel.redhat.com>
Message-ID: <1121853870.3606.9.camel@localhost.localdomain>


> Removed but not replaced were the dasd/tape s390 agents; these just created
> additional device symlinks for compatibility with really really old devfs
> installations; it's probably time for this compatiblity to be removed.

aye.... esp since we never shipped devfs in the first place ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050720/84fd926f/attachment.sig>

From buildsys at redhat.com  Wed Jul 20 11:29:31 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 20 Jul 2005 07:29:31 -0400
Subject: rawhide report: 20050720 changes
Message-ID: <200507201129.j6KBTQfs030558@porkchop.devel.redhat.com>

 

 
Updated Packages:

automake-1.9.6-1
----------------
* Tue Jul 19 2005 Karsten Hopp <karsten at redhat.de> 1.9.6-1
- Automake 1.9.6

* Sun Feb 13 2005 Florian La Roche <laroche at redhat.com>
- 1.9.5 bug-fix release

* Tue Feb 01 2005 Daniel Reed <djr at redhat.com> 1.9.4-1
- version bump
  - Portability nits in install-sh and mdata-sh.
  - Don't let `make install' fails if a _JAVA primary becomes empty
    because of conditionals.
  - Do not confuse CHANGELOG with ChangeLog on case-insensitive
    case-preserving file systems (likewise for all automatically
    distributed files).
  - Do not embed $DESTDIR in Python's byte-code files.
  - Work around programs that read stdin when checking for --version
    and --help options (when the `std-options' is used).
  - Fix AM_PATH_PYTHON to correctly define PYTHON as `:' when no minimum
    version was supplied and no interpreter is found.

bind-24:9.3.1-8
---------------
* Tue Jul 19 2005 Jason Vas Dias <jvdias at redhat.com> - 24:9.3.1-8
- fix named.init script bugs 163598, 163409, 151852(addendum)

devhelp-0.10-2
--------------
* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 0.10.0-2
- Rebuild against new mozilla
- Add builds for ia64 s390 s390x

epiphany-1.7.2-2
----------------
* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> - 1.7.2-2
- Rebuild against new mozilla

firefox-1.1-0.2.2.deerpark.alpha2
---------------------------------
* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.2-deerpark.alpha2
- Do away with firefox-rebuild-databases.pl

hotplug-3:2004_09_23-9
----------------------
* Tue Jul 19 2005 Bill Nottingham <notting at redhat.com> 3:2004_09_23-9
- move more things to udev - only input.agent, net.agent left

isdn4k-utils-3.2-31
-------------------
* Tue Jul 19 2005 Than Ngo <than at redhat.com> 3.2-31
- buildrequires on libpcap

jacorb-0:2.2-3jpp_3fc
---------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 0:2.2-3jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles idl jarfile).
- Add symbolic link in libgcj's extension directory.

* Mon Jun 27 2005 Gary Benson <gbenson at redhat.com> 0:2.2-3jpp_2fc
- BC-compile the main jarfile.

* Wed Jun 15 2005 Gary Benson <gbenson at redhat.com> 0:2.2-3jpp_1fc
- Build into Fedora.

jakarta-commons-beanutils-0:1.7.0-2jpp_2fc
------------------------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> - 0:1.7.0-2jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

jakarta-commons-collections-0:3.1-2jpp_2fc
------------------------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> - 0:3.1-2jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

jakarta-commons-digester-0:1.6-2jpp_6fc
---------------------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> - 0:1.6-2jpp_6fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles rss jarfile).

jakarta-commons-el-0:1.0-4jpp_2fc
---------------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> - 0:1.0-4jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

jakarta-commons-modeler-0:1.1-4jpp_2fc
--------------------------------------
* Wed Jul 20 2005 Gary Benson <gbenson at redhat.com> - 0:1.1-4jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_39rh
------------------------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_39rh
- Import java-gcj-compat 1.0.34.
- Provide servletapi and jspapi for bootstrapping.

java_cup-1:0.10-0.k.1jpp_5fc
----------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 1:0.10-0.k.1jpp_5fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

javacc-0:3.2-1jpp_3fc
---------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 0:3.2-1jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

* Tue Jul 05 2005 Andrew Overholt <overholt at redhat.com> 0:3.2-1jpp_2fc
- Bump release for FC4 update.

jonathan-rmi-3.1-5
------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 3.1-5
- Fix libgcj extension symlink.
libbtctl-0.4.1-8
----------------
* Tue Jul 19 2005 Harald Hoyer <harald at redhat.com> 0.4.1-8
- added gtk2-devel to BuildRequires

libieee1284-0.2.9-3
-------------------
* Tue Jul 19 2005 Tim Waugh <twaugh at redhat.com> 0.2.9-3
- Rebuild man pages.

man-pages-ja-20050715-1
-----------------------
* Wed Jul 20 2005 Akira TAGOH <tagoh at redhat.com> - 20050715-1
- updates to 20050715.

mkinitrd-4.2.18-1
-----------------
* Wed Jul 20 2005 Bill Nottingham <notting at redhat.com> - 4.2.18-1
- since udev is not in use, don't require it or claim to be starting it

mozilla-37:1.7.10-2
-------------------
* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.10-2
- Mozilla 1.7.10

mx4j-1:3.0.1-1jpp_4fc
---------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 0:3.0.1-1jpp_4fc
- Build on ia64, ppc64, s390 and s390x.
- Remove explicit references to jacorb and jonathan-rmi.
- Switch to aot-compile-rpm (also BC-compiles tools).

openoffice.org-1:1.9.118-1.2.0.fc5
----------------------------------
* Sat Jul 16 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.118-1
- add experiemental rh150643.fontconfigalwayssystemfont.vcl.patch
- drop integrated workspace.impress63.patch
- drop integrated workspace.mh19104.patch
- rh#163554# due to #i41296# missing FormWizard stuff

* Fri Jul 15 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-2
- add openoffice.org-1.9.117.ooo52023.evoadb2.nognuconst.patch to
  fix evoab2
- add openoffice.org-1.9.117.ooo52048.inhalt.sw.patch as minor .doc
  export regression fix for rh#158252#
- split email mailmerge stuff into a subpackage to avoid python
  dependancy on writer

patchutils-0.2.31-2
-------------------
* Tue Jul 19 2005 Tim Waugh <twaugh at redhat.com> 0.2.31-2
- Rebuilt to pick up new man-pages stylesheet.

ppp-2.4.3-2.1
-------------
* Tue Jul 19 2005 Thomas Woerner <twoerner at redhat.com> 2.4.3-2.1
- additional patch for the scripts, thanks to Sammy (#163621)

* Tue Jul 19 2005 Thomas Woerner <twoerner at redhat.com> 2.4.3-2
- dropped all executable bits in scripts directory to prevent rpm requiring
  programs used in there

radvd-0.8-2.FC5
---------------
* Mon Jul 18 2005 Jason Vas Dias <jvdias at redhat.com> 0.8.2.FC5
- fix bug 163593: must use '%configure' to get correct conf file location

selinux-policy-strict-1.25.3-2
------------------------------
* Tue Jul 19 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-2
- Update to latest from NSA

* Fri Jul 15 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-6
- Allow hald to run umount
- Don't allow users to use removable_t for mls policy

switchdesk-4.0.7-1
------------------
* Tue Jul 19 2005 Than Ngo <than at redhat.com> 4.0.7-1
- show more infos when it fails #162751
- add correct path for fluxbox #160433

system-config-printer-0.6.137-1
-------------------------------
* Tue Jul 19 2005 Tim Waugh <twaugh at redhat.com> 0.6.137-1
- 0.6.137:
  - Fixed Actions->Sharing... sensitivity (bug #163125).
  - Write configuration files in a way that SELinux likes.

tvtime-0.99-1
-------------
* Tue Jul 19 2005 Than Ngo <than at redhat.com> 0.99-1
- update to 0.99
- fix gcc4 build problem

udev-063-1
----------
* Tue Jul 19 2005 Bill Nottingham <notting at redhat.com> - 063-1
- update to 063
- handle the hotplug events for ieee1394, scsi, firmware

units-1.85-1
------------
* Tue Jul 19 2005 Harald Hoyer <harald at redhat.com> - 1.85-1
- version 1.85

xalan-j2-0:2.6.0-3jpp_3fc
-------------------------
* Tue Jul 19 2005 Gary Benson <gbenson at redhat.com> 0:2.6.0-3jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles xsltc and samples).

xfig-3.2.4-13
-------------
* Tue Jul 19 2005 Than Ngo <than at redhat.com> 3.2.4-13
- buildrequires on xorg-x11-devel

yelp-2.11.1-2
-------------
* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 2.11.1-2
- Rebuild against newer mozilla

Broken deps for i386
----------------------------------------------------------
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)



Broken deps for ppc
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf



Broken deps for s390x
----------------------------------------------------------
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	selinux-policy-strict - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	selinux-policy-strict-sources - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0



Broken deps for s390
----------------------------------------------------------
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	selinux-policy-strict-sources - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	selinux-policy-strict - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1



Broken deps for x86_64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	firstboot - 1.3.43-1.noarch requires system-config-display
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires struts >= 0:1.2.4
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5





From fedora at camperquake.de  Wed Jul 20 12:00:02 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 20 Jul 2005 14:00:02 +0200
Subject: Recent changes in the USB subsystem
Message-ID: <20050720140002.57d59117@nausicaa.camperquake.de>

Hi.

I am encountering some problems with my USB mouse with semi-current
kernels (kernel-2.6.12-1.1400_FC5 is affected, maybe earlier, too).

Sometimes mouse clicks are not recognized. Enabling the debug system
and listening on /sys/kernel/debug/usbmon/... shows that no USB
events are being generated for these missed clicks, either.
Some clicks are registered double, but this is far more rare.

Have there been changes to the kernel which may explain "lost"
USB events? Or is it more probable that a mechanical failure
has occured?

-- 
"It doesn't matter how fast your modem is if you're being shelled by
ethnic seperatists."  -- William Gibson



From peter.backlund at home.se  Wed Jul 20 12:35:23 2005
From: peter.backlund at home.se (Peter Backlund)
Date: Wed, 20 Jul 2005 14:35:23 +0200
Subject: rawhide report: 20050720 changes
In-Reply-To: <200507201129.j6KBTQfs030558@porkchop.devel.redhat.com>
References: <200507201129.j6KBTQfs030558@porkchop.devel.redhat.com>
Message-ID: <1121862923.10279.0.camel@ubuntu>


> 
> epiphany-1.7.2-2
> ----------------
> * Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> - 1.7.2-2
> - Rebuild against new mozilla

Any plans to start building packages against Firefox instead of
Seamonkey? Epiphany, Evolution, OO.org etc...

/Peter 




From russell at coker.com.au  Wed Jul 20 11:21:52 2005
From: russell at coker.com.au (Russell Coker)
Date: Wed, 20 Jul 2005 21:21:52 +1000
Subject: /dev/random changes
Message-ID: <200507202121.56061.russell@coker.com.au>

It seems that the behavior of /dev/random has changed recently in rawhide.

I have a machine configured to use an encrypted swap space with /dev/random as 
the source for the key via the "-d /dev/random" option to cryptsetup.

Until recently the command "cryptsetup -d /dev/random create swap /dev/hda2" 
completed in a reasonable amount of time.  Now it will hang almost 
indefinitely (I've waited for over 16 minutes).  Pressing the SHIFT, CTRL, and 
ALT keys repeatedly during the boot process can make cryptsetup complete in 
as little as a second.

It seems to me that previous kernels used some entropy that's available during 
boot (such as interrupts from the hard disk) and recent kernels have stopped 
doing so.

Is this a bug or a feature?

-- 
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



From dnjinc at wowway.com  Wed Jul 20 13:24:37 2005
From: dnjinc at wowway.com (Demond James)
Date: Wed, 20 Jul 2005 09:24:37 -0400
Subject: anybody have firefox-1.1-0.2.1.deerpark.alpha2 working?
In-Reply-To: <dbl53e$k2c$1@sea.gmane.org>
References: <dbl53e$k2c$1@sea.gmane.org>
Message-ID: <42DE5095.7030104@wowway.com>

sean wrote:

> It doesn't start at all for me.
>
> I also tried:
>
>  ./firefox-bin
> ./firefox-bin: error while loading shared libraries: libmozjs.so: 
> cannot open shared object file: No such file or directory
>
> which of course is in the same directory - /usr/lib64/firefox-1.1 - 
> but that's without all the script variables.
>
> sean
>
I got mine to start after I renamed my ~/.mozilla folder and let firefox 
create a new one.  Don't know if I had the same error though.  Typing 
firefox in a terminal window did not display anything, it just didn't start.



From pbrobinson at gmail.com  Wed Jul 20 13:26:58 2005
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 20 Jul 2005 14:26:58 +0100
Subject: anybody have firefox-1.1-0.2.1.deerpark.alpha2 working?
In-Reply-To: <42DE5095.7030104@wowway.com>
References: <dbl53e$k2c$1@sea.gmane.org> <42DE5095.7030104@wowway.com>
Message-ID: <5256d0b050720062616bf92ac@mail.gmail.com>

On 7/20/05, Demond James <dnjinc at wowway.com> wrote:
> sean wrote:
> 
> > It doesn't start at all for me.
> >
> > I also tried:
> >
> >  ./firefox-bin
> > ./firefox-bin: error while loading shared libraries: libmozjs.so:
> > cannot open shared object file: No such file or directory
> >
> > which of course is in the same directory - /usr/lib64/firefox-1.1 -
> > but that's without all the script variables.
> >
> > sean
> >
> I got mine to start after I renamed my ~/.mozilla folder and let firefox
> create a new one.  Don't know if I had the same error though.  Typing
> firefox in a terminal window did not display anything, it just didn't start.

I recompiled t the src rpm under FC4 so I could use it without all
devel requirements and its working excellent here with no problems at
all.

Pete



From jspaleta at gmail.com  Wed Jul 20 13:27:48 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 20 Jul 2005 09:27:48 -0400
Subject: anybody have firefox-1.1-0.2.1.deerpark.alpha2 working?
In-Reply-To: <dbl53e$k2c$1@sea.gmane.org>
References: <dbl53e$k2c$1@sea.gmane.org>
Message-ID: <604aa79105072006272b05b971@mail.gmail.com>

On 7/20/05, sean <seandarcy2 at gmail.com> wrote:
> It doesn't start at all for me.

worksforme on my 32bit pc

-jef



From caillon at redhat.com  Wed Jul 20 14:55:55 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 20 Jul 2005 10:55:55 -0400
Subject: rawhide report: 20050720 changes
In-Reply-To: <1121862923.10279.0.camel@ubuntu>
References: <200507201129.j6KBTQfs030558@porkchop.devel.redhat.com>
	<1121862923.10279.0.camel@ubuntu>
Message-ID: <42DE65FB.90104@redhat.com>

Peter Backlund wrote:
>>epiphany-1.7.2-2
>>----------------
>>* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> - 1.7.2-2
>>- Rebuild against new mozilla
> 
> 
> Any plans to start building packages against Firefox instead of
> Seamonkey? Epiphany, Evolution, OO.org etc...

Epiphany, yes.  Evolution, OO.org, no.  The idea is Evo and friends only need the security stuff in the NSS library, which is a separate product than the browsers.  They should build against that.  The blocker bug is must be able to compile Firefox, Mozilla, etc. --with-system-nss

The upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=255408

Once that gets fixed, I can start building things against firefox.  I don't want to shift the NSS problem from mozilla to firefox though.



From fedora at wir-sind-cool.org  Wed Jul 20 15:49:00 2005
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 20 Jul 2005 17:49:00 +0200
Subject: anybody have firefox-1.1-0.2.1.deerpark.alpha2 working?
In-Reply-To: <604aa79105072006272b05b971@mail.gmail.com>
References: <dbl53e$k2c$1@sea.gmane.org>
	<604aa79105072006272b05b971@mail.gmail.com>
Message-ID: <20050720174900.795aaf73.fedora@wir-sind-cool.org>

On Wed, 20 Jul 2005 09:27:48 -0400, Jeff Spaleta wrote:

> On 7/20/05, sean <seandarcy2 at gmail.com> wrote:
> > It doesn't start at all for me.
> 
> worksforme on my 32bit pc

"doesn't start at all" sounds familiar:
https://bugzilla.redhat.com/163653



From dwmw2 at infradead.org  Wed Jul 20 18:23:02 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 20 Jul 2005 14:23:02 -0400
Subject: rawhide report: 20050719 changes
In-Reply-To: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
References: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
Message-ID: <1121883783.12903.48.camel@localhost.localdomain>

On Tue, 2005-07-19 at 07:38 -0400, Build System wrote:
> * Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com>
> 1.1-0.0.1.deerpark.alpha2
> - Update to Deer Park Alpha 2
>   - STILL TODO:
>     - This build is not localized yet.
>     - Theme issues not yet resolved.
>     - Building on ppc platforms is busted, disable them for now.

Is there a bug filed for this? We should ideally have a bug filed for
_all_ arch exclusions.

-- 
dwmw2



From caillon at redhat.com  Wed Jul 20 18:28:06 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 20 Jul 2005 14:28:06 -0400
Subject: rawhide report: 20050719 changes
In-Reply-To: <1121883783.12903.48.camel@localhost.localdomain>
References: <200507191138.j6JBcIYx016803@porkchop.devel.redhat.com>
	<1121883783.12903.48.camel@localhost.localdomain>
Message-ID: <42DE97B6.2010901@redhat.com>

On 07/20/2005 02:23 PM, David Woodhouse wrote:

>On Tue, 2005-07-19 at 07:38 -0400, Build System wrote:
>  
>
>>* Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com>
>>1.1-0.0.1.deerpark.alpha2
>>- Update to Deer Park Alpha 2
>>  - STILL TODO:
>>    - This build is not localized yet.
>>    - Theme issues not yet resolved.
>>    - Building on ppc platforms is busted, disable them for now.
>>    
>>
>
>Is there a bug filed for this? We should ideally have a bug filed for
>_all_ arch exclusions.
>
There is an easy way to figure that out.  Query :)  I didn't file one, 
though. But someone may have by now.  The issue seems to be in the 
toolchain.  Get problems compiling with memcpy at GCC3.3.2 stuff (I thought 
I had the log saved but can't find it) -- disabling the visibility 
pragma gets this to build on non-i386 platforms, yet still doesn't work 
for ppc.  ppc64 traditionally has not built, although I have a patch 
which I believe fixes that once the other issues are cleared up.



From monpetitbeurre at gmail.com  Thu Jul 21 00:11:24 2005
From: monpetitbeurre at gmail.com (Nic)
Date: Wed, 20 Jul 2005 19:11:24 -0500
Subject: Stateless linux and an idea of mine for SMALL networks without
	servers
Message-ID: <ac13d58205072017116e8f7b6b@mail.gmail.com>

I was fighting the usual problems with networks and came up with the
following dream to make my life easier as a network admin. Basically I
am tired of fixing things, of worrying if a hard disk will die, of
having to deal with data access, backup etc...

Anyway here it is: Basically, I suggest that (almost) all PCs in the
network be laptops with the exact same image. Furthermore, they
replicate their HD continuously!!! I am not sure of the technology to
use here, but I thought something deriving from the P-to-P technology,
some distributed file system, some database replication technology or
even freenet could be a good base. Since every laptop will contain ALL
the data for the whole network, every laptop uses hardware encryption
at the hard disk level using an external dongle/card/whatever.

Additionally, every login ALSO uses a dongle/card for access to their
account. This makes it (almost) impossible for somebody stealing a
laptop to get access to the whole data. Additionally, it makes it
(alomst) impossible for somebody to fet to other people's data. If a
system dies, you just get a new one and sync it up. However, one main
idea is that you always have EVERYTHING you need right where you are,
no matter WHERE you are. Also, there is no UPS to worry about.
Communication between PCs could be implemented using VPN/IPSec or
whatever other protected mechanism. Internet access would have to be
"sandboxed", but UNIX based OSes allow for that easily. That's the
gist of it. A lot of things can be configured in many ways, but the
whole point here is to simplify people's life.

I wanted to post it here for other people to use if they think it's a
good idea. (and also to preempt any proprietary company from saying
"me first")



I posted this somewhere and somebody pointed me toward stateless linux
and it seems pretty cool and close to what I was thinking of. I'll
look smoe more into it, but does anybody see this as useful for VERY
SMALL networks? (I already got bashed by enterprise admins sneernig at
people who don't want a rack server, so if that's your intent, just
reply "me too").

Nick



From buildsys at redhat.com  Thu Jul 21 11:29:43 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 21 Jul 2005 07:29:43 -0400
Subject: rawhide report: 20050721 changes
Message-ID: <200507211129.j6LBThas013795@porkchop.devel.redhat.com>

 

 
Updated Packages:

alsa-lib-1.0.9rf-3
------------------
* Wed Jul 20 2005 Martin Stransky <stransky at redhat.com> 1.0.9rf-3
- check for /var/run/console/console.lock (#162982)

anaconda-10.3.0.6-1
-------------------
* Wed Jul 20 2005 Paul Nasrat <pnasrat at redhat.com> 10.3.0.6-1
- Ensure boot flag only on correct partition on pmac (#157245)
- Plug in yum for nfs:/ by default
- Include sungem_phy for pmac

binutils-2.16.91.0.1-3
----------------------
* Thu Jul 21 2005 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.1-3
- fix buffer overflow in readelf ia64 unwind printing code
- use vsnprintf rather than vsprintf in gas diagnostics (Tavis Ormandy)
- fix ld-cdtest when CFLAGS contains -fexceptions

* Wed Jul 20 2005 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.1-2
- update to 20050720 CVS

* Mon Jul 11 2005 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.1-1
- update to 2.16.91.0.1-1 plus 20050708 CVS

firefox-0:1.0.6-1.1.fc4
-----------------------
* Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.6-1.1.fc4
- Update to 1.0.6

* Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.6-0.1.fc4
- 1.0.6 Release Candidate

* Tue May 24 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.4-4
- Only install searchplugins for en-US, since there isn't any way
  to dynamically select searchplugins per locale yet.

firefox-1.1-0.2.3.deerpark.alpha2
---------------------------------
* Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.3-deerpark.alpha2
- Update firefox-1.1-uriloader.patch to fix crashes when calling into gnome-vfs2

freeradius-1.0.4-2
------------------
* Wed Jul 20 2005 Thomas Woerner <twoerner at redhat.com> 1.0.4-2
- added missing build requires for libtool-ltdl-devel (#160877)
- modified file list to get a report for missing plugins

gcc-4.0.1-4
-----------
* Wed Jul 20 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.1-4
- update from CVS
  - PRs c++/22132, c++/22139, c++/22263, c/22421, fortran/13257,
	fortran/20842, fortran/21034, libfortran/18857, libfortran/21333,
	libfortran/21480, libfortran/21593, libfortran/21594,
	libfortran/21926, libfortran/22142, libfortran/22144,
	libstdc++/21193, middle-end/22057, target/21721, testsuite/21969
  - avoid discarding volatile casts (Richard Henderson, #162274,
    PR tree-opt/22278)
  - fix -frepo (Mark Mitchell, #163271, PR c++/22204)
- ensure debug info for C static file-scope vars is emitted with
  -g -O[23] (PR debug/21828)
- fix fortran handling of repeated character literals in DATA (#163394,
  PR fortran/20063)
- avoid sibling calls if structure arguments passed by value overlap
  (#163058)
- work around PR middle-end/20606 (Andrew Haley)
- fix fortran output of -Infinity for length 3 (Jerry DeLisle)
- fix fortran handling of trailing blanks in exponents (Jerry DeLisle)

iiimf-1:12.2-8
--------------
* Wed Jul 20 2005 Akira TAGOH <tagoh at redhat.com> - 1:12.2-8
- leif-unit-fix-key-twice-r2614-162646.patch: backported a patch from
  upstream to get fixed the displaying character twice issue. (#162646)
- leif-unit-fix-freeze-with-flipping-focus-r2664.patch: backported a patch
  from upstream to get fixed the freeze issue with flipping focus.
- leif-unit-fix-deadkey-sequence-r2729.patch: backported a patch from
  upstream to get fixed the deadkey sequence issue.
- iiimgcf-fix-hang-r2757.patch: backported a patch from upstream to get
  fixed the applications freezes with pressing key during the focus is grabbed.
- iiimsf-fix-memory-leak-r2764.patch: backported a patch from upstream to
  get fixed the memory leak issue.
- iiimp-fix-memory-leak-r2770.patch: likewise.

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_40rh
------------------------------------------
* Wed Jul 20 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_40rh
- Import java-gcj-compat 1.0.35.

mozilla-37:1.7.10-3
-------------------
* Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.10-3
- Add firefox-1.0-pango-cairo.patch to get rid of the last few Xft
  references, fixing the "no fonts" problem.

net-tools-1.60-55
-----------------
* Wed Jul 20 2005 Radek Vokal <rvokal at redhat.com> 1.60-55
- ifconfig - fixed virtual interface dropping (#162888)

netatalk-4:2.0.3-2
------------------
* Wed Jul 20 2005 Bill Nottingham <notting at redhat.com>
- don't run by default

nut-2.0.2-1
-----------
* Wed Jul 20 2005 Than Ngo <than at redhat.com> 2.0.2-1
- fix compiler warnings #156027
- fix pid issue  #159450
- fix wrong ownership and permissions #159449, #141123
- update to 2.0.2

openoffice.org-1:1.9.119-1.2.0.fc5
----------------------------------
* Wed Jul 20 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.119-1
- experiment with security flags
- drop integrated cmcfixes11.workspace
- drop integrated openoffice.org-1.9.113.ooo51385.bridges.stack.patch
- drop integrated openoffice.org-1.9.118.ooo52061.recursive.animations.patch

pcmciautils-006-1
-----------------

qt-1:3.3.4-17
-------------
* Wed Jul 20 2005 Than Ngo <than at redhat.com> 1:3.3.4-17
- fix German translation of the Qt Assistent #161558

* Mon Jun 27 2005 Than Ngo <than at redhat.com> 1:3.3.4-16
- apply patch to fix Rendering for Punjabii, thanks to Trolltech #156504

* Tue May 24 2005 Than Ngo <than at redhat.com> 1:3.3.4-15
- add better fix for #156977, thanks to trolltech
- apply patch to fix keyReleaseEvent problem #156572

struts-0:1.2.4-2jpp_2fc
-----------------------
* Wed Jul 20 2005 Gary Benson <gbenson at redhat.com> - 0:1.2.4-2jpp_2fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles webapps).

ypserv-2.13-7
-------------
* Thu Jun 23 2005 Chris Feist <cfeist at redhat.com> - 2.13-7
- Fix crash with ypxfr caused by failing to zero out data (bz #161217)

Broken deps for x86_64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)



Broken deps for i386
----------------------------------------------------------
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1



Broken deps for ia64
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	struts-webapps-tomcat5 - 1.2.4-2jpp_2fc.ia64 requires tomcat5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16



Broken deps for s390
----------------------------------------------------------
	selinux-policy-strict - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	struts-webapps-tomcat5 - 1.2.4-2jpp_2fc.s390 requires tomcat5
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	selinux-policy-strict-sources - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf



Broken deps for s390x
----------------------------------------------------------
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	struts-webapps-tomcat5 - 1.2.4-2jpp_2fc.s390x requires tomcat5
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	selinux-policy-targeted-sources - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	selinux-policy-targeted - 1.25.2-5.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	selinux-policy-strict-sources - 1.25.3-2.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0



Broken deps for ppc64
----------------------------------------------------------
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	struts-webapps-tomcat5 - 1.2.4-2jpp_2fc.ppc64 requires tomcat5
	jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	jonas - 4.3.3-1jpp_5fc.noarch requires tomcat5 >= 0:5.0.30
	jonas - 4.3.3-1jpp_5fc.noarch requires jasper5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	firstboot - 1.3.43-1.noarch requires system-config-display
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)





From rodd at clarkson.id.au  Thu Jul 21 12:45:06 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Thu, 21 Jul 2005 22:45:06 +1000
Subject: rawhide report: 20050721 changes
In-Reply-To: <200507211129.j6LBThas013795@porkchop.devel.redhat.com>
References: <200507211129.j6LBThas013795@porkchop.devel.redhat.com>
Message-ID: <1121949907.2918.7.camel@moose>

On Thu, 2005-07-21 at 07:29 -0400, Build System wrote:

> firefox-0:1.0.6-1.1.fc4
> -----------------------
> * Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.6-1.1.fc4
> - Update to 1.0.6
> 
> * Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.6-0.1.fc4
> - 1.0.6 Release Candidate
> 
> * Tue May 24 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.4-4
> - Only install searchplugins for en-US, since there isn't any way
>   to dynamically select searchplugins per locale yet.
> 
> firefox-1.1-0.2.3.deerpark.alpha2
> ---------------------------------
> * Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.3-deerpark.alpha2
> - Update firefox-1.1-uriloader.patch to fix crashes when calling into gnome-vfs2

Can these be installed in parallel, and if so, how hard would it be to
rename the firefox-1.1-0.2.3.deerpark.alpha2 to deerpark and to use
deerpark to launch it?

This would allow people to use firefox and deerpark at the same time.


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From caillon at redhat.com  Thu Jul 21 15:03:37 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 21 Jul 2005 11:03:37 -0400
Subject: rawhide report: 20050721 changes
In-Reply-To: <1121949907.2918.7.camel@moose>
References: <200507211129.j6LBThas013795@porkchop.devel.redhat.com>
	<1121949907.2918.7.camel@moose>
Message-ID: <42DFB949.2020907@redhat.com>

On 07/21/2005 08:45 AM, Rodd Clarkson wrote:

>On Thu, 2005-07-21 at 07:29 -0400, Build System wrote:
>
>  
>
>>firefox-0:1.0.6-1.1.fc4
>>-----------------------
>>* Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.6-1.1.fc4
>>- Update to 1.0.6
>>
>>* Mon Jul 18 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.6-0.1.fc4
>>- 1.0.6 Release Candidate
>>
>>* Tue May 24 2005 Christopher Aillon <caillon at redhat.com> 0:1.0.4-4
>>- Only install searchplugins for en-US, since there isn't any way
>>  to dynamically select searchplugins per locale yet.
>>
>>firefox-1.1-0.2.3.deerpark.alpha2
>>---------------------------------
>>* Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.3-deerpark.alpha2
>>- Update firefox-1.1-uriloader.patch to fix crashes when calling into gnome-vfs2
>>    
>>
>
>Can these be installed in parallel, and if so, how hard would it be to
>rename the firefox-1.1-0.2.3.deerpark.alpha2 to deerpark and to use
>deerpark to launch it?
>
>This would allow people to use firefox and deerpark at the same time.
>
No, they are not only not parallel installable, but they are not both 
available for download from the devel repo.  I'm not sure why this lists 
both, but it seems to be a hiccup in the script.  The fc4 package listed 
*will not work* on rawhide (before anyone gets the idea to try it).



From dwmw2 at infradead.org  Thu Jul 21 16:39:06 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 21 Jul 2005 12:39:06 -0400
Subject: rawhide report: 20050721 changes
In-Reply-To: <42DFB949.2020907@redhat.com>
References: <200507211129.j6LBThas013795@porkchop.devel.redhat.com>
	<1121949907.2918.7.camel@moose>  <42DFB949.2020907@redhat.com>
Message-ID: <1121963947.20077.35.camel@localhost.localdomain>

On Thu, 2005-07-21 at 11:03 -0400, Christopher Aillon wrote:
> No, they are not only not parallel installable, but they are not both 
> available for download from the devel repo.  I'm not sure why this lists 
> both, but it seems to be a hiccup in the script.  The fc4 package listed 
> *will not work* on rawhide (before anyone gets the idea to try it).

The FC4 package got inherited into rawhide/ppc, which it why it showed
up on the report.

-- 
dwmw2



From buildsys at redhat.com  Fri Jul 22 11:13:32 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 22 Jul 2005 07:13:32 -0400
Subject: rawhide report: 20050722 changes
Message-ID: <200507221113.j6MBDW1Z019967@porkchop.devel.redhat.com>

 

 
Updated Packages:

alsa-utils-1.0.9rf-4
--------------------
* Wed Jul 13 2005 Bill Nottingham <notting at redhat.com> 1.0.9-4
- migrate the alsa restore program to a udev rule, not a dev.d program
- conflict with appropriate udev
- move alsaunmute, alsacard to /bin

ant-0:1.6.2-3jpp_13fc
---------------------
* Thu Jul 21 2005 Gary Benson <gbenson at redhat.com> 0:1.6.2-3jpp_13fc
- Disable the style and xmlvalidate tasks on ppc64 and s390x (#163689).

binutils-2.16.91.0.2-1
----------------------
* Fri Jul 22 2005 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.2-1
- update to 2.16.91.0.2

doxygen-1:1.4.4-1
-----------------
* Thu Jul 21 2005 Than Ngo <than at redhat.com> 1:1.4.4-1
- update to 1.4.4

eclipse-bugzilla-1:0.1.1_fc-5
-----------------------------
* Thu Jul 21 2005 Jeff Pound <jpound at redhat.com> 0.1.1_fc-5
- BuildRequire gcc-java 4.0.1.

* Thu Jul 21 2005 Jeff Pound <jpound at redhat.com> 0.1.1_fc-4
- Remove bugzilla.redhat.com/bugzilla-old pre-set (no longer online).
- Finalize support for new bugzilla.redhat.com (pending https bug#158893).
- Update Apply Patch functionality.
- Refactor query options parser.

fetchmail-6.2.5.2-1
-------------------
* Fri Jul 22 2005 Miloslav Trmac <mitr at redhat.com> - 6.2.5.2-1
- Update to fetchmail-6.2.5.2

* Thu Jul 21 2005 Miloslav Trmac <mitr at redhat.com> - 6.2.5.1-1
- Update to fetchmail-6.2.5.1 to fix CAN-2005-2355 (#163819)
- Fix crash on empty Message-ID

glibc-2.3.90-4
--------------
* Fri Jul 22 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-4
- update from CVS
  - make sure bits/wchar2.h header is installed
  - fix __getgroups_chk return type

* Thu Jul 21 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-3
- update from CVS
  - make sure nscd cmsg buffers aren't misaligned, handle EINTR from
    poll when contacting nscd more gracefully
  - remove malloc attribute from posix_memalign
  - correctly size nscd buffer for grpcache key (#163538)
  - fix atan2f
  - fix error memory leaks
  - some more _FORTIFY_SOURCE protection

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_41rh
------------------------------------------
* Thu Jul 21 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_41rh
- Remove servletapi and jspapi now that tomcat5 is built.

libselinux-1.24.2-1
-------------------
* Mon Jul 18 2005 Dan Walsh <dwalsh at redhat.com> 1.24.2-1
- Update makefiles

mx4j-1:3.0.1-1jpp_5fc
---------------------
* Fri Jul 22 2005 Gary Benson <gbenson at redhat.com> 0:3.0.1-1jpp_5fc
- Remove workarounds for #163689.

netpbm-10.28-4
--------------
* Thu Jul 21 2005 Jindrich Novy <jnovy at redhat.com> 10.28-4
- fix buffer overflow in pbmtolj (#163596)

pcmciautils-006-2
-----------------

selinux-policy-strict-1.25.3-3
------------------------------
* Tue Jul 19 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-3
- Fix spec file for file_context.homedirs

selinux-policy-targeted-1.25.3-3
--------------------------------
* Tue Jul 19 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-3
- Fix spec file for file_context.homedirs

* Tue Jul 19 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-2
- Update to latest from NSA

* Fri Jul 15 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-6
- Allow hald to run umount
- Don't allow users to use removable_t for mls policy

struts-0:1.2.4-2jpp_3fc
-----------------------
* Fri Jul 22 2005 Gary Benson <gbenson at redhat.com> - 0:1.2.4-2jpp_3fc
- Remove workarounds for #163689.

tomcat5-0:5.0.30-8jpp_1fc
-------------------------
* Thu Jul 21 2005 Gary Benson <gbenson at redhat.com> 0:5.0.30-8jpp_1fc
- Build on ia64, ppc64, s390 and s390x.

* Thu Jul 21 2005 Gary Benson <gbenson at redhat.com> 0:5.0.30-8jpp
- Correct ownership of admin webapps directory.

* Wed Jul 20 2005 Gary Benson <gbenson at redhat.com>
- Remove jarfiles from the tarball.
- Switch to aot-compile-rpm.

zlib-1.2.2.2-5
--------------
* Fri Jul 22 2005 Ivana Varekova <varekova at redhat.com> 1.2.2.2-5
- fix bug 163038 - CAN-2005-1849 - zlib buffer overflow

Broken deps for i386
----------------------------------------------------------
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	firstboot - 1.3.43-1.noarch requires system-config-display
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3



Broken deps for s390x
----------------------------------------------------------
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3



Broken deps for s390
----------------------------------------------------------
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219





From seandarcy2 at gmail.com  Fri Jul 22 12:03:34 2005
From: seandarcy2 at gmail.com (sean)
Date: Fri, 22 Jul 2005 08:03:34 -0400
Subject: OK: anybody have firefox-1.1-0.2.*3*.deerpark.alpha2 working?
Message-ID: <dbqnam$arf$1@sea.gmane.org>

It doesn't even start. The scripts just give an exit code of 
1. Starting it directly doesn't work:

$ /usr/lib64/firefox-1.1/firefox-bin -UILocale en-US
/usr/lib64/firefox-1.1/firefox-bin: error while loading 
shared libraries: libmozjs.so: cannot open shared object 
file: No such file or directory

though libmozjs.so is there.

sean



From casimiro.barreto at gmail.com  Fri Jul 22 12:57:46 2005
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 22 Jul 2005 09:57:46 -0300
Subject: OK: anybody have firefox-1.1-0.2.*3*.deerpark.alpha2 working?
In-Reply-To: <dbqnam$arf$1@sea.gmane.org>
References: <dbqnam$arf$1@sea.gmane.org>
Message-ID: <42E0ED4A.8070802@gmail.com>

Same here...
After messing everything in order to put it to work, when I finally got
a working window, the preferences menu simply messes with fonts
(pt_BR.UTF8) and I have no visible text. Thunderbird is also in a mess
(no/invisible fonts).

sean wrote:

> It doesn't even start. The scripts just give an exit code of 1.
> Starting it directly doesn't work:
>
> $ /usr/lib64/firefox-1.1/firefox-bin -UILocale en-US
> /usr/lib64/firefox-1.1/firefox-bin: error while loading shared
> libraries: libmozjs.so: cannot open shared object file: No such file
> or directory
>
> though libmozjs.so is there.
>
> sean
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050722/9549e6ec/attachment.sig>

From aoliva at redhat.com  Fri Jul 22 14:46:56 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 22 Jul 2005 11:46:56 -0300
Subject: No more right click terminal
In-Reply-To: <1121462167.4036.32.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
Message-ID: <orackesxsv.fsf@livre.redhat.lsd.ic.unicamp.br>

Sorry for bringing this old thread back to life, I've been away from
the list for a bit, and I think there are some very important points
that have failed to make into this discussion.

On Jul 15, 2005, Colin Walters <walters at redhat.com> wrote:

> On Thu, 2005-07-14 at 14:32 -0300, Alexandre Oliva wrote:
>> On Jul 13, 2005, Colin Walters <walters at redhat.com> wrote:
>> 
>> > Think of it this way: what if GNOME's historical audience had been
>> > musicians?  Then the right click menu might have had 
>> > "Open Musical Score Composer".  Having that makes as much sense to the
>> > general population as "Open Terminal" does.
>> 
>> FWIW, when I first introduced Cygwin to a musician friend of mine, he
>> absolutely *loved* the ability to issue commands without having to
>> point and click, and the ability to write scripts to automate common
>> or repetitive tasks.

> If your friend can write scripts, that means he or she has a level of
> technical knowledge we can not expect of all users.

He doesn't have such knowledge, and he can't write scripts (yet?).
What he can do is ask me how to do certain actions he does often from
the command line, then type those, one after the other, into a file,
and then make that file executable.  Oops, there's a script.  The
difficult bit is to figure out how to accomplish the point-and-click
actions from a command line.

>> Terminals should not be thought of as power-users only; they're useful
>> for everybody.

> Completely, totally disagree.  Every time a non-developer/non-sysadmin
> has to use the terminal for something is a bug.

I don't disagree with your point.  One *should* be able to accomplish
anything from the GUI.  But that was not my point.

My point was that, in *addition* to being able to accomplish actions
with the GUI interaction mechanisms, it would be ideal to *also* be
able to accomplish those same actions from a scripting language,
because this would enable users who happen to repeat the same
sequences of actions to script them.  It would enable other GUI
applications to record sequences of events to replay them later, to
ease scripting for users who still fear the command line.  It would
enable better testing of GUI apps, and would also enable users who
become power users to exercise their power to make themselves more
productive instead of remaining point-and-click monkeys who can just
wish they could do more.

>> Perhaps our desktop approach should take a stance
>> similar to AIX SMIT (sp?), a system administration front-end that
>> would not only enable you to perform various tasks with a point&click
>> interface, but *also* let you know the commands it was running to
>> perform those tasks.  

> Let me suggest something to you - what if we took an stance with GCC
> where when it compiled C code, it popped up a curses application which
> told you how you could be writing by hand the assembler it was
> generating and how it was doing.  Here's how the register allocator
> works, here's how it optimized away variable x, etc...

Why does it have to pop up a curses application?  Why not just give
users the *option* to see the assembly code they could use to
accomplish the same tasks by hand?  Why not give users the *option*
for the compiler to tell what it's doing behind the scenes, and let
users inspect what's going on in each of the optimization passes?  Oh,
wait, GCC can already do this, and some users see a *lot* of value in
that.

And there's more: if you want, you can take some of the assembly code,
tweak it, and feed it back into the compiler through the extended
asm() notation introduced by GCC, that's one of its most interesting
features for really low-level, power developers.

So, GCC already has means to let people watch what's going on behind
the scenes, if they choose to.  Unfortunately, there are still some
missing bits.  It would be very nice if GCC would expose its internal
API such that people could easily plug their own optimization passes
into, and we could feed code using GCC's internal representations into
certain passes.  This comes up every now and then in GCC lists, and
it's agreed that it would be useful, but we can't do it for political
reasons: the FSF won't let us do it because of fear that this would
make it too easy for people to develop proprietary extensions for GCC.
So we end up with a poorer testsuite and no plugin features, but
that's not because they're not desirable.

> Now, I happen to be one of the people who is in the target audience for
> GCC.  The entire reason I use GCC is because I don't *want* to know or
> care about assembler.  Just like our desktop, for the vast majority of
> people, GCC is a tool they use to get a job done, not something they
> care to know the internals of.  The curses/GCC thing would be extremely
> annoying at best for people just trying to get a job done, exactly like
> your suggestion of desktop commands would be.

If it's forced down everybody's throat, yes, it would be quite
annoying.  But it is useful for a number of people, and if you force
the *inability* to use such features down these people, you make
*them* unhappy.

>> I'm told Autocad is very much like this as well,
>> and even architects without any prior programming expertise end up
>> being able to automate tasks using the lisp-based programming
>> interface, which is one of the features that makes it so powerful.

> Autocad is a very specialized tool for a particular audience.  You can
> probably assume that most of its users spend 8 hours a day for years in
> front of it and that any time they can save helps a lot.

And isn't this the case for lots of applications that people use day
after day?

> The same is not true in general.  It is not worth the time for most
> users to learn how to program just so you can save a few seconds off
> your OpenOffice usage or whatever.

Sure, if they don't see the need for that, they don't have to.  But
the many that could do that would benefit from it.

> Don't get me wrong: it *would* be nice if we had an equivalent to
> AppleScript so somewhat technically inclined users could script apps for
> relatively obscure use cases.  But that's no substitute for actually
> fixing the desktop to just work for the major cases.

What is it that makes use cases that someone has to perform 100 times
a day obscure?  The fact that this person is not your idealized target
user?  Everybody deviates a bit from this user, so, by denying this
ability to everybody, you're making everybody's life harder.

>> This gave you the option to remain clueless 

> I think this reveals a lot about how you think about our target users.

Or about my lack of command of the English language.  I'm not a native
speaker.  Perhaps this term doesn't mean what I meant.  I just meant
the user could remain in...  would the term `blissful ignorance' not
carry the negative connotation you read into my words?

> If you consider them "clueless" and think that they have some need to
> know how computers work and how to program or else they're stupid, that
> strikes me as rather negative and arrogant.

cluelessness and stupidity are not quite the same.  One can choose to
remain ignorant on some topic that they think doesn't make much of a
difference to them.  Stupidity is related with someone trying hard to
acquire some knowledge, but still fails, because the topic is just too
difficult for them.

> Personally, I think *we* are the clueless ones, who spend all of our
> time in front of computers learning how they work.  The truly smart
> people are the ones who became surfing instructors at some beach in
> Hawaii and rarely see a computer.

Personally, I find it more fun to hack than to turn into a red tomato
at the a beach.  But then, I'm known to be geeky and nerdy :-)

> People in general want to use the computer to do their work, send email
> occasionally or something, and could care less how they work at all (and
> definitely don't care to learn how to program).

Sure, we shouldn't stop such people from using computers.  But even
those might have use cases that could be improved, and if they can't
come up with a solution themselves, they can keep on wasting their
time on such repetitive tasks, or they could ask a computer-savvy
friend to write a script for them, or write a script themselves,
after some studying, or even using a GUI app to create GUI scripts.

> You'd think this would be common sense...I feel pretty silly even
> explaining it.

I feel just the same way about the thoughts I've exposed above.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From walters at redhat.com  Fri Jul 22 15:23:51 2005
From: walters at redhat.com (Colin Walters)
Date: Fri, 22 Jul 2005 11:23:51 -0400
Subject: No more right click terminal
In-Reply-To: <orackesxsv.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<orackesxsv.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <1122045832.28171.12.camel@nexus.verbum.private>

On Fri, 2005-07-22 at 11:46 -0300, Alexandre Oliva wrote:

> > I think this reveals a lot about how you think about our target users.
> 
> Or about my lack of command of the English language.  I'm not a native
> speaker.  Perhaps this term doesn't mean what I meant.  I just meant
> the user could remain in...  would the term `blissful ignorance' not
> carry the negative connotation you read into my words?

My apologies then.  It's an attitude I've seen from many other people
and it frustrates me a lot.

> Sure, we shouldn't stop such people from using computers.  But even
> those might have use cases that could be improved, and if they can't
> come up with a solution themselves, they can keep on wasting their
> time on such repetitive tasks, or they could ask a computer-savvy
> friend to write a script for them, or write a script themselves,
> after some studying, or even using a GUI app to create GUI scripts.

Going back to the original point of this thread, not having the terminal
in the right-click menu is not going to help these people at all if they
need some computer-savvy friend to introduce them and start writing
things for them.  Having it there by default is not going to magically
endow knowledge of data structures, scripting languages, variables, etc.

Again, no one is suggesting removing the terminal; power users can
easily add it to the panel or install nautilus-open-terminal.  Or just
launch it from the menu; personally I have one terminal with 10 tabs
restored as part of my session and never open a new one.

That's all I have to say.






From Nicolas.Mailhot at laPoste.net  Fri Jul 22 15:52:56 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Fri, 22 Jul 2005 17:52:56 +0200
Subject: No more right click terminal
In-Reply-To: <1122045832.28171.12.camel@nexus.verbum.private>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<orackesxsv.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1122045832.28171.12.camel@nexus.verbum.private>
Message-ID: <1122047577.25999.26.camel@rousalka.dyndns.org>

Le vendredi 22 juillet 2005 ? 11:23 -0400, Colin Walters a ?crit :

> Going back to the original point of this thread, not having the terminal
> in the right-click menu is not going to help these people at all if they
> need some computer-savvy friend to introduce them and start writing
> things for them.  Having it there by default is not going to magically
> endow knowledge of data structures, scripting languages, variables, etc.

But the terminal menu entry will help the computer-savvy friend when he
needs to describe over the telephone how to do something. It will help
the people that formalise this kind of advice in howtos. It will help
those of us who mail small scripts to friends because that's easier than
take them through a computer 101 course (not taking into account that
because we are friends or family we are supposed to take abuse pupils
would never dare vent at a paid teacher). Because the terminal can do
all the advanced things you write about does not mean people need to
master all of them to use it (indeed if one had to have this level of
knowledge use a tool most office suite users would never be allowed to
touch them). The terminal is the power user swiss knife but it's also
the computer illiterate crutch (not that being a tool power users like
should be ground for eradiction)

Removing a facility to promote another (that is not even fully existing
yet) has never been a graceful or constructive way to change things.
That it forces rewriting of documentation should be a red light. Writing
technical documentation, like explaining something you think you
understand to total strangers, is a pretty good way to find out what's
really simple clear and useful and what isn't.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050722/52f05ad1/attachment.sig>

From caillon at redhat.com  Fri Jul 22 17:59:16 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 22 Jul 2005 13:59:16 -0400
Subject: OK: anybody have firefox-1.1-0.2.*3*.deerpark.alpha2 working?
In-Reply-To: <dbqnam$arf$1@sea.gmane.org>
References: <dbqnam$arf$1@sea.gmane.org>
Message-ID: <42E133F4.90207@redhat.com>

On 07/22/2005 08:03 AM, sean wrote:

> It doesn't even start. The scripts just give an exit code of 1. 
> Starting it directly doesn't work:
>
> $ /usr/lib64/firefox-1.1/firefox-bin -UILocale en-US
> /usr/lib64/firefox-1.1/firefox-bin: error while loading shared 
> libraries: libmozjs.so: cannot open shared object file: No such file 
> or directory

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163665#c5



From fedora at iagorubio.com  Fri Jul 22 19:23:05 2005
From: fedora at iagorubio.com (Iago Rubio)
Date: Fri, 22 Jul 2005 21:23:05 +0200
Subject: No more right click terminal
In-Reply-To: <1122047577.25999.26.camel@rousalka.dyndns.org>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<orackesxsv.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1122045832.28171.12.camel@nexus.verbum.private>
	<1122047577.25999.26.camel@rousalka.dyndns.org>
Message-ID: <1122060186.26064.68.camel@speedy.iagorubio.net>

On Fri, 2005-07-22 at 17:52 +0200, Nicolas Mailhot wrote:
> Le vendredi 22 juillet 2005 ? 11:23 -0400, Colin Walters a ?crit :
> 
> > Going back to the original point of this thread, not having the terminal
> > in the right-click menu is not going to help these people at all if they
> > need some computer-savvy friend to introduce them and start writing
> > things for them.  Having it there by default is not going to magically
> > endow knowledge of data structures, scripting languages, variables, etc.
> 
> But the terminal menu entry will help the computer-savvy friend when he
> needs to describe over the telephone how to do something. It will help
> the people that formalise this kind of advice in howtos. It will help
> those of us who mail small scripts to friends because that's easier than
> take them through a computer 101 course (not taking into account that
> because we are friends or family we are supposed to take abuse pupils
> would never dare vent at a paid teacher). 

I disagree a bit with you here, as the "Applications" menu is always
visible in the panel, and to say over the phone "... click the menu item
at Applications/System Tools/Terminal ... " is not going to kill anyone.

Furthermore you'll be teaching this user where the system tools are
located, so he's learning the right way to do it, and not driving him to
think he should look for random menu entries at random menus to
accomplish a task.

>From the HIG: "The Applications menu, which appears on the panel at the
top of the screen by default, is the primary mechanism by which users
discover and run applications."
http://developer.gnome.org/projects/gup/hig/2.0/desktop-
integration.html#desktop-application-menu

I say a "random menu" here because from a usability point of view the
"Terminal" menu entry in the Desktop contextual menu is a mess - IMHO.

Contextual menus should have a meaning in a given context, as when you
right click in a block device icon and the menu shows a "Mount Volume"
entry. It's bound to the device and it's only applicable in this
context.

>From the HIG: "Popup menus provide shortcuts to those menu items that
are applicable only to the currently selected object."
http://developer.gnome.org/projects/gup/hig/2.0/menus-types.html#menu-
type-popup

The "Terminal" entry in the "Desktop" contextual menu, may drive a
clueless user to think the "Terminal" thing have something to do with
the Desktop - that's not true.

Even worst, this entry opens a shell cd-ing to $HOME and not to the
Desktop folder, so it's even more confusing. A user selecting a menu
item - on the desktop contextual menu - to open a Terminal window should
be moved to the Desktop folder not to $HOME.

With this in mind, I think that to drop this entry out of the Desktop
contextual menu is much better for clueless users.

For those with computer-savvy friends, they can always ask them to add a
little script to the $HOME/.gnome2/nautilus-scripts folder, with those
lines:

#!/bin/sh

filedir=$(echo $NAUTILUS_SCRIPT_CURRENT_URI|sed -e s#file://##)
selecteddir=$( echo "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS"|sed -e s#
$filedir/##)

for directory in $selecteddir; do
	eval "cd $filedir/$directory;gnome-terminal&"
done

This way - once this script is made executable - it will appear on the
desktop - and nautilus - contextual menus under the "Scripts" sub-menu,
labeled with the file's name - "Open_Terminal" may be a good name.

> Removing a facility to promote another (that is not even fully 
> existing yet) has never been a graceful or constructive way to
> change things.

Sure, but maintaining a wrong item in the Desktop menu because people is
used to it, is nor a graceful, neither a constructive way to improve the
desktop environment.

Users expect consistency among menu actions, and the contextual menu -
the "pop menu" - should trigger actions on the currently selected
object, and should not execute random commands - despite of the command
itself being really useful, or totally useless.

ITOH It's sure people used to this menu entry should be confused by the
lack of it, but the should be able to find the terminal entry on the
"Applications" menu. If they're unable to do it, they're learning the
wrong way to use the Gnome desktop, and it will be much better to show
them the basics of Gnome. 


Regards.
-- 
Iago Rubio <fedora at iagorubio.com>



From Nicolas.Mailhot at laPoste.net  Fri Jul 22 20:48:03 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Fri, 22 Jul 2005 22:48:03 +0200
Subject: No more right click terminal
In-Reply-To: <1122060186.26064.68.camel@speedy.iagorubio.net>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<1121245649.12224.28.camel@localhost.localdomain>
	<1121248417.16074.19.camel@goose>
	<1121274056.10565.15.camel@nexus.verbum.private>
	<orfyuhs37f.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1121462167.4036.32.camel@nexus.verbum.private>
	<orackesxsv.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1122045832.28171.12.camel@nexus.verbum.private>
	<1122047577.25999.26.camel@rousalka.dyndns.org>
	<1122060186.26064.68.camel@speedy.iagorubio.net>
Message-ID: <1122065283.25999.59.camel@rousalka.dyndns.org>

Le vendredi 22 juillet 2005 ? 21:23 +0200, Iago Rubio a ?crit :

> I disagree a bit with you here, as the "Applications" menu is always
> visible in the panel, and to say over the phone "... click the menu item
> at Applications/System Tools/Terminal ... " is not going to kill anyone.

More indirections as writing it shows. And obviously you've only ever
worked with power users ;) (at least they are compared to some of mine
if you consider this "will never kill anyone")

> Furthermore you'll be teaching this user where the system tools are
> located, so he's learning the right way to do it,

Some users resent being taught. And will actively blame you if you even
suggest you're addressing more than the actual problem they want you to
take care of.

> The "Terminal" entry in the "Desktop" contextual menu, may drive a
> clueless user to think the "Terminal" thing have something to do with
> the Desktop - that's not true.

The root windows is the starting point of common tasks. Terminal entry
belongs there - it's a common workflow starting point. Wallpaper does
not - it's not a common task. You are actually confusing the desktop
metaphor with the real computer science desktop object, which has always
been a task starting point and nothing else.

> Even worst, this entry opens a shell cd-ing to $HOME and not to the
> Desktop folder, so it's even more confusing.

That's because someone decided to throw computer logic out of the window
to get an empty desktop root. As others have noted, if you're willing to
take ?sthetical considerations aside, $HOME=desktop is the natural thing
to do. Do not blame cli root and gui root separation on the terminal.
They may be physically distinct now but are functionaly the same.

> A user selecting a menu
> item - on the desktop contextual menu - to open a Terminal window should
> be moved to the Desktop folder not to $HOME.

Again, you're confusing the computer object you have in your mind with
the function users want. Users that use the terminal entry in the root
window will want to be taken to the natural shell root, which the
Desktop folder isn't. All you're gaining is exposing the bad logic that
presided to the $HOME-Desktop separation.

> With this in mind, I think that to drop this entry out of the Desktop
> contextual menu is much better for clueless users.
> 
> For those with computer-savvy friends, they can always ask them to add a
> little script to the $HOME/.gnome2/nautilus-scripts folder, with those
> lines:
...

If you want clueless users to do it pray write the documentation I'll
laugh 

If you want the computer-savy friends to do it don't you think if they
had this kind of control they wouldn't need to do remote-control by
phone ? The whole point is to be able to help a user with a pristine
unmodified system.

> Users expect consistency among menu actions, and the contextual menu -
> the "pop menu" - should trigger actions on the currently selected
> object, and should not execute random commands - despite of the command
> itself being really useful, or totally useless.

If a command is really useful in any context it's 100% appropriate.
People who disagree on this based on the metaphor they're trying to
build always end up in the GUI hall of shame.

The point is not to build a system consistent with an abstract object,
but with the actual software objects people use. That's why computer
mice have their tail the same side as their ears, even if consistency
with living mice would mandate moving it to the other end.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050722/f64ca44b/attachment.sig>

From rodd at clarkson.id.au  Fri Jul 22 05:00:58 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 22 Jul 2005 15:00:58 +1000
Subject: SVG not being handles by Firefox Deer Park
Message-ID: <1122008458.7477.2.camel@localhost.localdomain>

Trying to open

	http://www.croczilla.com/svg/samples/arcs1/arcs1.svg

in Firefox (Deer Park) results in a dialog asking what I'd like to do
with this file.

Given that svg.enabled is set to true in about:config, shouldn't
deerpark just render this svg image rather than trying to hand if off to
another application?

Is there a mime type issue that needs to be addressed, and should I file
a bugzilla on this?


Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From drepper at redhat.com  Fri Jul 22 23:43:32 2005
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 22 Jul 2005 16:43:32 -0700
Subject: SVG not being handles by Firefox Deer Park
In-Reply-To: <1122008458.7477.2.camel@localhost.localdomain>
References: <1122008458.7477.2.camel@localhost.localdomain>
Message-ID: <42E184A4.5070707@redhat.com>

Rodd Clarkson wrote:
> Given that svg.enabled is set to true in about:config, shouldn't
> deerpark just render this svg image rather than trying to hand if off to
> another application?

Last time I tried using the SVG support (it's been a while) it handled
only embedded SVG.  I.e., no SVG files by itself.  Create a normal XHTML
file, add a namespace definition for SVG, and then use prefixed svg tags.

<html
xmlns:svg="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.svg"
        xmlns="http://www.w3.org/TR/REC-html40">
<body>
 <svg:svg width="260" height="80">
  <svg:g>
   <svg:polygon class="arrow" points="192 54 184 72 225 65 254 74 254 6
222 33 223 15 190 29 195 14 158 27 156 14 110 30 110 18 75 39 70 26 1 48
71 48 77 59 99 44 99 56 135 42 136 60 165 46 160 62" />


etc etc

-- 
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050722/de091394/attachment.sig>

From caillon at redhat.com  Sat Jul 23 00:02:44 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 22 Jul 2005 20:02:44 -0400
Subject: SVG not being handles by Firefox Deer Park
In-Reply-To: <1122008458.7477.2.camel@localhost.localdomain>
References: <1122008458.7477.2.camel@localhost.localdomain>
Message-ID: <42E18924.8000608@redhat.com>

Rodd Clarkson wrote:
> Trying to open
> 
> 	http://www.croczilla.com/svg/samples/arcs1/arcs1.svg
> 
> in Firefox (Deer Park) results in a dialog asking what I'd like to do
> with this file.
> 
> Given that svg.enabled is set to true in about:config, shouldn't
> deerpark just render this svg image rather than trying to hand if off to
> another application?
> 
> Is there a mime type issue that needs to be addressed, and should I file
> a bugzilla on this?

The short answer is because I didn't build with --enable-svg.

Interesting timing to send this as I was building an RPM locally with that option before I read your mail just now.  Assuming things build fine, I'll turn that on, with a few other things in the next build of deerpark.



From rodd at clarkson.id.au  Sat Jul 23 04:15:59 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sat, 23 Jul 2005 14:15:59 +1000
Subject: SVG not being handles by Firefox Deer Park
In-Reply-To: <42E184A4.5070707@redhat.com>
References: <1122008458.7477.2.camel@localhost.localdomain>
	<42E184A4.5070707@redhat.com>
Message-ID: <1122092159.2993.18.camel@moose>

On Fri, 2005-07-22 at 16:43 -0700, Ulrich Drepper wrote:
> Rodd Clarkson wrote:
> > Given that svg.enabled is set to true in about:config, shouldn't
> > deerpark just render this svg image rather than trying to hand if off to
> > another application?
> 
> Last time I tried using the SVG support (it's been a while) it handled
> only embedded SVG.  I.e., no SVG files by itself.  Create a normal XHTML
> file, add a namespace definition for SVG, and then use prefixed svg tags.
> 
> <html
> xmlns:svg="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.svg"
>         xmlns="http://www.w3.org/TR/REC-html40">
> <body>
>  <svg:svg width="260" height="80">
>   <svg:g>
>    <svg:polygon class="arrow" points="192 54 184 72 225 65 254 74 254 6
> 222 33 223 15 190 29 195 14 158 27 156 14 110 30 110 18 75 39 70 26 1 48
> 71 48 77 59 99 44 99 56 135 42 136 60 165 46 160 62" />
> 
> 
Ulrich

Yeah, I found another page that had embedded SVG and even this didn't
work.  I get the feeling (based on caillon's email) that things might
improve dramatically when caillon enables SVG ;-]


Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From divij at innomedia.soft.net  Sat Jul 23 10:57:52 2005
From: divij at innomedia.soft.net (divij bhatt)
Date: Sat, 23 Jul 2005 16:27:52 +0530
Subject: fonts
Message-ID: <1122116272.6845.2.camel@localhost.localdomain>

Hi,
    I am using Fedora core 2 I want to know that how can I install a
particular font into the system.

Thanks in Advance
Divij



From ivazquez at ivazquez.net  Sat Jul 23 11:07:19 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Sat, 23 Jul 2005 07:07:19 -0400
Subject: fonts
In-Reply-To: <1122116272.6845.2.camel@localhost.localdomain>
References: <1122116272.6845.2.camel@localhost.localdomain>
Message-ID: <1122116839.24638.12.camel@ignacio.lan>

On Sat, 2005-07-23 at 16:27 +0530, divij bhatt wrote:
>     I am using Fedora core 2 I want to know that how can I install a
> particular font into the system.

http://www.fedoralegacy.org/

Also, this mailing list isn't for end-user support.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050723/f6da907e/attachment.sig>

From buildsys at redhat.com  Sat Jul 23 11:13:21 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 23 Jul 2005 07:13:21 -0400
Subject: rawhide report: 20050723 changes
Message-ID: <200507231113.j6NBDLmO002609@porkchop.devel.redhat.com>

New package systemtap
	Instrumentation System


 
Updated Packages:

anaconda-10.3.0.7-1
-------------------
* Thu Jul 21 2005 Chris Lumens <clumens at redhat.com> 10.3.0.7-1
- Remove firewall configuration screen.  Open SSH by default and set
  SELinux to enforced.

dovecot-0.99.14-6.fc5
---------------------
* Fri Jul 22 2005 John Dennis <jdennis at redhat.com> - 0.99.14-6.fc5
- fix bug #149673, add dummy PAM_TTY

* Thu Apr 28 2005 John Dennis <jdennis at redhat.com> - 0.99.14-5.fc4
- fix bug #156159 insecure location of restart flag file

elfutils-0.109-2
----------------
* Fri Jul 22 2005 Roland McGrath <roland at redhat.com> - 0.109-2
- update to 0.109
  - verify that libebl modules are from the same build
  - new eu-elflint checks on copy relocations
  - new program eu-elfcmp
  - new experimental libdwfl library

file-4.14-2
-----------
* Fri Jul 22 2005 Radek Vokal <rvokal at redhat.com> - 4.14-2
- fixed mime types recognition (#163866) <mandriva.org>

firefox-1.1-0.2.4.deerpark.alpha2
---------------------------------
* Fri Jul 22 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.4.deerpark.alpha2
- Add patch from Christian Persch to make the file chooser modal
- Change default behavior of opening links from external apps to: New Tab
- New build options:
  --enable-svg
  --enable-canvas

* Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.3.deerpark.alpha2
- Update firefox-1.1-uriloader.patch to fix crashes when calling into gnome-vfs2

* Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.2.deerpark.alpha2
- Do away with firefox-rebuild-databases.pl

gdb-6.3.0.0-1.49
----------------
* Fri Jul 22 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.49
- Bump up release number.

* Fri Jul 22 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.46
- Fix attaching to 32-bit processes on 64-bit systems.
- Bugzilla 160254

* Thu Jul 14 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.45
- Bump up release number.

geronimo-specs-0:1.0-0.M2.2jpp_4fc
----------------------------------
* Fri Jul 22 2005 Gary Benson <gbenson at redhat.com> 0:1.0-0.M2.2jpp_4fc
- Switch to aot-compile-rpm.
- Also build jta.
- Build on ia64, ppc64, s390 and s390x.

glibc-2.3.90-5
--------------
* Fri Jul 22 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-5
- update from CVS
  - fix stubs.h generation
- don't use _G_va_list in bits/wchar2.h

hplip-0.9.4-1
-------------
* Fri Jul 22 2005 Tim Waugh <twaugh at redhat.com> 0.9.4-1
- forward-decl patch not needed.
- 0.9.4.

iiimf-1:12.2-9
--------------
* Fri Jul 22 2005 Akira TAGOH <tagoh at redhat.com> - 1:12.2-9
- iiimgcf-deadkey.patch: applied to get the dead key working. (#163944)

* Thu Jul 21 2005 Akira TAGOH <tagoh at redhat.com>
- xiiimp-pango.patch: updated.
  - fixed to spot the correct location for the lookup window at the OverTheSpot.
    (#135368)

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_42rh
------------------------------------------
* Fri Jul 22 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_42rh
- Remove jta compatibility stuff.

kdenetwork-7:3.4.1-2
--------------------
* Fri Jul 22 2005 Than Ngo <than at redhat.com> 7:3.4.1-2
- fix crash in kopete on x86_64
- apply patch to fix libgadu vulnerabilities #163811, CVE CAN-2005-1852
  thank to kde security team

kudzu-1.1.118-1
---------------
* Fri Jul 22 2005 Bill Nottingham <notting at redhat.com> 1.1.118-1
- make sure ISAPNP devices don't end up as CLASS_UNSPEC (#163949)

* Thu Jun 16 2005 Bill Nottingham <notting at redhat.com>
- fix usb - class/subclass/protocol are hex, not decimal (#160450)

* Wed May 18 2005 Bill Nottingham <notting at redhat.com> 1.1.117-1
- probe ACPI PnP devices as well (#146405)
- tweak synaptics detection for ALPS (#158062, <pnasrat at redhat.com>)

libgal2-2:2.4.3-2
-----------------
* Fri Jul 22 2005 David Malcolm <dmalcolm at redhat.com> - 2:2.4.3-2
- fix sources

* Fri Jul 22 2005 David Malcolm <dmalcolm at redhat.com> - 2:2.4.3-1
- 2.4.3

libraw1394-1.2.0-1.fc5
----------------------
* Fri Jul 22 2005 Warren Togami <wtogami at redhat.com> - 1.2.0-1
- 1.2.0

module-init-tools-3.2-0.pre7.2
------------------------------
* Fri Jul 22 2005 Bill Nottingham <notting at redhat.com> 3.2-0.pre7.2
- fix depmod segfault on bad modules (#162716)

openoffice.org-1:1.9.120-1.2.0.fc5
----------------------------------
* Wed Jul 20 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.120-1
- drop redundant workspace.dummywebwizard.patch

* Wed Jul 20 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.119-2
- re-experiment with execshield GNU_STACK non X

pam-0.80-3
----------
* Fri Jul 22 2005 Tomas Mraz <tmraz at redhat.com> 0.80-3
- more pam_selinux permissive fixes (Dan Walsh)
- make binaries PIE (#158938)

subversion-1.2.1-3
------------------
* Fri Jul 22 2005 Joe Orton <jorton at redhat.com> 1.2.0-3
- update to 1.2.1
- fix BuildRequires for ruby and apr-util (#163126)
- drop static library archives

synaptics-0:0.14.3-1
--------------------
* Fri Jul 22 2005 Paul Nasrat <pnasrat at redhat.com> - 0:0.14.3-1
- Update to 0.14.3

system-config-netboot-0.1.22-1_FC5
----------------------------------
* Fri Jul 22 2005 Jason Vas Dias <jvdias at redhat.com> 0.1.22-1
- fix bugs 164011, 164012:
  updateDiskless now resolves missing module dependencies in the
  initrd, and returns an error for missing module files and executables.
- fix bug 161904: fix tooltips in pxeosdialog and NFS server label

totem-1.1.3-1
-------------
* Fri Jul 22 2005 Colin Walters <walters at redhat.com> - 1.1.3-1
- Update to upstream version 1.1.2

Broken deps for i386
----------------------------------------------------------
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21



Broken deps for s390x
----------------------------------------------------------
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)



Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1





From jspaleta at gmail.com  Sat Jul 23 17:54:40 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 23 Jul 2005 13:54:40 -0400
Subject: SVG not being handles by Firefox Deer Park
In-Reply-To: <42E18924.8000608@redhat.com>
References: <1122008458.7477.2.camel@localhost.localdomain>
	<42E18924.8000608@redhat.com>
Message-ID: <604aa791050723105427dde91f@mail.gmail.com>

On 7/22/05, Christopher Aillon <caillon at redhat.com> wrote:
> Interesting timing to send this as I was building an RPM locally with that option 
> before I read your mail just now.  Assuming things build fine, I'll turn that on, with a 
> few other things in the next build of deerpark.

Just FYI, today's rawhide package  firefox-1.1-0.2.4.deerpark.alpha2
seems to work fine with the svg in the original post in this thread.

-jef



From bgerst at didntduck.org  Sat Jul 23 18:05:29 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Sat, 23 Jul 2005 14:05:29 -0400
Subject: rawhide report: 20050723 changes
In-Reply-To: <200507231113.j6NBDLmO002609@porkchop.devel.redhat.com>
References: <200507231113.j6NBDLmO002609@porkchop.devel.redhat.com>
Message-ID: <42E286E9.30509@didntduck.org>

Build System wrote:
> firefox-1.1-0.2.4.deerpark.alpha2
> ---------------------------------
> * Fri Jul 22 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.4.deerpark.alpha2
> - Add patch from Christian Persch to make the file chooser modal
> - Change default behavior of opening links from external apps to: New Tab
> - New build options:
>   --enable-svg
>   --enable-canvas
> 
> * Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.3.deerpark.alpha2
> - Update firefox-1.1-uriloader.patch to fix crashes when calling into gnome-vfs2
> 
> * Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.2.deerpark.alpha2
> - Do away with firefox-rebuild-databases.pl

Still busted on x86_64

--
				Brian Gerst



From mike at miketc.com  Sat Jul 23 19:42:51 2005
From: mike at miketc.com (Mike Chambers)
Date: Sat, 23 Jul 2005 19:42:51 +0000
Subject: Rawhide updates & Fonts
Message-ID: <1122147771.4269.1.camel@scrappy.miketc.com>

With a fully updated FC4 + full rawhide updates, are the fonts still as
messed up as they have been recently, especially in evolution and
firefox (even with the alpha one?)?

Not running it, just trying to keep track before going back to a rawhide
system like I do between releases (yes I help test, open bugs, etc.. and
aware of rawhide).

Thanks,

-- 
Mike Chambers
Madisonville, KY

"Everything is always harder, before it's easier!



From caillon at redhat.com  Sat Jul 23 20:13:34 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 23 Jul 2005 16:13:34 -0400
Subject: rawhide report: 20050723 changes
In-Reply-To: <42E286E9.30509@didntduck.org>
References: <200507231113.j6NBDLmO002609@porkchop.devel.redhat.com>
	<42E286E9.30509@didntduck.org>
Message-ID: <42E2A4EE.7080109@redhat.com>

Brian Gerst wrote:
> Build System wrote:
> 
>> firefox-1.1-0.2.4.deerpark.alpha2
>> ---------------------------------
>> * Fri Jul 22 2005 Christopher Aillon <caillon at redhat.com> 
>> 1.1-0.2.4.deerpark.alpha2
>> - Add patch from Christian Persch to make the file chooser modal
>> - Change default behavior of opening links from external apps to: New Tab
>> - New build options:
>>   --enable-svg
>>   --enable-canvas
>>
>> * Wed Jul 20 2005 Christopher Aillon <caillon at redhat.com> 
>> 1.1-0.2.3.deerpark.alpha2
>> - Update firefox-1.1-uriloader.patch to fix crashes when calling into 
>> gnome-vfs2
>>
>> * Tue Jul 19 2005 Christopher Aillon <caillon at redhat.com> 
>> 1.1-0.2.2.deerpark.alpha2
>> - Do away with firefox-rebuild-databases.pl
> 
> 
> Still busted on x86_64

That may be because the changelog doesn't say anything about "fix bustedness on x64_64".

In seriousness, "busted" means nothing to anybody other than you, honestly.  I've already referenced https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163665 on this list which seems like it may be your issue.  If it is not, then I suggest filing your own bug with information more useful than "busted" such as a gdb backtrace if available and a strace if that's all you have.  Any other details you can think of are useful as well.



From Nicolas.Mailhot at laPoste.net  Sat Jul 23 20:15:31 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sat, 23 Jul 2005 22:15:31 +0200
Subject: Rawhide updates & Fonts
In-Reply-To: <1122147771.4269.1.camel@scrappy.miketc.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
Message-ID: <1122149732.11316.0.camel@rousalka.dyndns.org>

Le samedi 23 juillet 2005 ? 19:42 +0000, Mike Chambers a ?crit :
> With a fully updated FC4 + full rawhide updates, are the fonts still as
> messed up as they have been recently, especially in evolution and
> firefox (even with the alpha one?)?

Fonts are still messed a bit in Firefox (size). No complaints with Evo.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050723/ed565e0c/attachment.sig>

From caillon at redhat.com  Sat Jul 23 20:19:46 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 23 Jul 2005 16:19:46 -0400
Subject: Rawhide updates & Fonts
In-Reply-To: <1122147771.4269.1.camel@scrappy.miketc.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
Message-ID: <42E2A662.7050406@redhat.com>

Mike Chambers wrote:
> With a fully updated FC4 + full rawhide updates, are the fonts still as
> messed up as they have been recently, especially in evolution and
> firefox (even with the alpha one?)?

Describe "messed up."  The only issue I'm aware of exists when using FC4-updates packages, which apparently happens in some occasions (some yum mirror picks up the FC4 update changes before it picks up the rawhide changes?)



From mike at miketc.com  Sat Jul 23 20:35:43 2005
From: mike at miketc.com (Mike Chambers)
Date: Sat, 23 Jul 2005 15:35:43 -0500
Subject: Rawhide updates & Fonts
In-Reply-To: <42E2A662.7050406@redhat.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<42E2A662.7050406@redhat.com>
Message-ID: <1122150943.4269.4.camel@scrappy.miketc.com>

On Sat, 2005-07-23 at 16:19 -0400, Christopher Aillon wrote:
> Mike Chambers wrote:
> > With a fully updated FC4 + full rawhide updates, are the fonts still as
> > messed up as they have been recently, especially in evolution and
> > firefox (even with the alpha one?)?
> 
> Describe "messed up."  The only issue I'm aware of exists when using FC4-updates packages, which apparently happens in some occasions (some yum mirror picks up the FC4 update changes before it picks up the rawhide changes?)

Do the fonts still render diff/not as good with the (cairo?) changes
that are taking place?  In other words, do they still not look quite as
good from rawhide as the previous Fedora releases?


-- 
Mike Chambers
Madisonville, KY

"Everything is always harder, before it's easier!



From caillon at redhat.com  Sat Jul 23 20:40:17 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 23 Jul 2005 16:40:17 -0400
Subject: Rawhide updates & Fonts
In-Reply-To: <1122150943.4269.4.camel@scrappy.miketc.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>	<42E2A662.7050406@redhat.com>
	<1122150943.4269.4.camel@scrappy.miketc.com>
Message-ID: <42E2AB31.2060003@redhat.com>

Mike Chambers wrote:
> On Sat, 2005-07-23 at 16:19 -0400, Christopher Aillon wrote:
> 
>>Mike Chambers wrote:
>>
>>>With a fully updated FC4 + full rawhide updates, are the fonts still as
>>>messed up as they have been recently, especially in evolution and
>>>firefox (even with the alpha one?)?
>>
>>Describe "messed up."  The only issue I'm aware of exists when using FC4-updates packages, which apparently happens in some occasions (some yum mirror picks up the FC4 update changes before it picks up the rawhide changes?)
> 
> 
> Do the fonts still render diff/not as good with the (cairo?) changes
> that are taking place?  In other words, do they still not look quite as
> good from rawhide as the previous Fedora releases?

Still not as good?  As far as I know, they have always looked fine.  I've not seen any complaints in bugzilla.  Not sure where the idea is coming from that the quality of fonts has been deteriorating.



From rodd at clarkson.id.au  Sat Jul 23 21:23:49 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 24 Jul 2005 07:23:49 +1000
Subject: Rawhide updates & Fonts
In-Reply-To: <42E2AB31.2060003@redhat.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<42E2A662.7050406@redhat.com>
	<1122150943.4269.4.camel@scrappy.miketc.com>
	<42E2AB31.2060003@redhat.com>
Message-ID: <1122153829.3070.7.camel@localhost.localdomain>

On Sat, 2005-07-23 at 16:40 -0400, Christopher Aillon wrote:
> Mike Chambers wrote:
> > On Sat, 2005-07-23 at 16:19 -0400, Christopher Aillon wrote:
> > 
> >>Mike Chambers wrote:
> >>
> >>>With a fully updated FC4 + full rawhide updates, are the fonts still as
> >>>messed up as they have been recently, especially in evolution and
> >>>firefox (even with the alpha one?)?
> >>
> >>Describe "messed up."  The only issue I'm aware of exists when using FC4-updates packages, which apparently happens in some occasions (some yum mirror picks up the FC4 update changes before it picks up the rawhide changes?)
> > 
> > 
> > Do the fonts still render diff/not as good with the (cairo?) changes
> > that are taking place?  In other words, do they still not look quite as
> > good from rawhide as the previous Fedora releases?
> 
> Still not as good?  As far as I know, they have always looked fine.  I've not seen any complaints in bugzilla.  Not sure where the idea is coming from that the quality of fonts has been deteriorating.
> 
I'm not sure if anyone filed a bug report.  Some comments were made on
this list (or was it testing) that the fonts were a little 'different'
and indeed some of the fonts were a little blurrier (IMHO).  For
example, the '-' seemed to have a little blur on top of it.

However, Own popped up on the very same list (in responds the the very
same thread) and commented that things were still being tuned and should
improve.

I think it's fair to say that things have improved and that the fonts
look very nice now.  However, this may be because I've grown used to
them now, but I don't think it is (since the '-' doesn't have a little
'growth' on top of it).

Most of the above comments are based on fact, with a little tongue in
cheek thrown in for good measure. ;-]


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jspaleta at gmail.com  Sat Jul 23 21:27:16 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 23 Jul 2005 17:27:16 -0400
Subject: Rawhide updates & Fonts
In-Reply-To: <1122153829.3070.7.camel@localhost.localdomain>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<42E2A662.7050406@redhat.com>
	<1122150943.4269.4.camel@scrappy.miketc.com>
	<42E2AB31.2060003@redhat.com>
	<1122153829.3070.7.camel@localhost.localdomain>
Message-ID: <604aa79105072314275bf3724c@mail.gmail.com>

On 7/23/05, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> I think it's fair to say that things have improved and that the fonts
> look very nice now.  However, this may be because I've grown used to
> them now, but I don't think it is (since the '-' doesn't have a little
> 'growth' on top of it).
> 
> Most of the above comments are based on fact, with a little tongue in
> cheek thrown in for good measure. ;-]

Its very hard to talk about rendering issues unless we build up a
flipbook of screencaptures that show the differences between different
package builds in a standardized way.  I suffer from the same
perception issue when it comes to rendering details.. I just fail to
notice rendering anomolies as problems and just get use to them unless
they can be pointed out to me.

-jef



From rodd at clarkson.id.au  Sat Jul 23 21:32:31 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 24 Jul 2005 07:32:31 +1000
Subject: SVG not being handles by Firefox Deer Park
In-Reply-To: <604aa791050723105427dde91f@mail.gmail.com>
References: <1122008458.7477.2.camel@localhost.localdomain>
	<42E18924.8000608@redhat.com>
	<604aa791050723105427dde91f@mail.gmail.com>
Message-ID: <1122154351.3070.17.camel@localhost.localdomain>

On Sat, 2005-07-23 at 13:54 -0400, Jeff Spaleta wrote:
> On 7/22/05, Christopher Aillon <caillon at redhat.com> wrote:
> > Interesting timing to send this as I was building an RPM locally with that option 
> > before I read your mail just now.  Assuming things build fine, I'll turn that on, with a 
> > few other things in the next build of deerpark.
> 
> Just FYI, today's rawhide package  firefox-1.1-0.2.4.deerpark.alpha2
> seems to work fine with the svg in the original post in this thread.

Ah, Jef, you beat me too it.

I noticed last night that the SVG stuff was 'mostly' working but it was
bed time so I marked this message as important to reply about it in the
morning.

I too noticed that the SVG rendering was now working.  Thanks caillon.
I'm very impressed how fast these images render.

However I also noticed that some of the other samples in the same area
( http://www.croczilla.com/svg/samples/ ) weren't working (the SVG was
appearing, but the actions weren't working).

For example:


the background isn't appearing is this example:
http://www.croczilla.com/svg/samples/circles2/circles2.xml

the roll-over doesn't work in this sample:
http://www.croczilla.com/svg/samples/events1/events1.xml

you can't drag the circle in this example:
http://www.croczilla.com/svg/samples/events2/events2.xml

This example doesn't appear to render properly
http://www.croczilla.com/svg/samples/foreign1/foreign1.xml

And gradients don't seem to work.
http://www.croczilla.com/svg/samples/gradients1/gradients1.svg
http://www.croczilla.com/svg/samples/gradients2/gradients2.svg


There are probably other examples on this page that don't work, but
those are just a few.

Should we expect that these are working, or is it already known (up
stream) that these need to be addressed?


Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From rodd at clarkson.id.au  Sat Jul 23 21:52:04 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 24 Jul 2005 07:52:04 +1000
Subject: Rawhide updates & Fonts
In-Reply-To: <604aa79105072314275bf3724c@mail.gmail.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<42E2A662.7050406@redhat.com>
	<1122150943.4269.4.camel@scrappy.miketc.com>
	<42E2AB31.2060003@redhat.com>
	<1122153829.3070.7.camel@localhost.localdomain>
	<604aa79105072314275bf3724c@mail.gmail.com>
Message-ID: <1122155525.3070.26.camel@localhost.localdomain>

On Sat, 2005-07-23 at 17:27 -0400, Jeff Spaleta wrote:
> On 7/23/05, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> > I think it's fair to say that things have improved and that the fonts
> > look very nice now.  However, this may be because I've grown used to
> > them now, but I don't think it is (since the '-' doesn't have a little
> > 'growth' on top of it).
> > 
> > Most of the above comments are based on fact, with a little tongue in
> > cheek thrown in for good measure. ;-]
> 
> Its very hard to talk about rendering issues unless we build up a
> flipbook of screencaptures that show the differences between different
> package builds in a standardized way.  I suffer from the same
> perception issue when it comes to rendering details.. I just fail to
> notice rendering anomolies as problems and just get use to them unless
> they can be pointed out to me.

Yeah, agreed.  Perception is a dangerous comparison tool. ;-

The biggest 'tell' for me that things have improved is that the '-'
character now looks like it's a single row of pixels, instead of looking
like two blurry rows.  This one stands out because I used to wonder why
Mac OS X handled it so badly given that 'their' font rendering was
supposed to be so good.

I will say this about perception of font rendering.  I (until recently)
worked in a mixed desktop environment with graphic artists.  Desktops
were mostly Mac OS X with a couple of Windows desktops and my GNOME
based linux box.  Comments were made (and I had thought the same thing)
on numerous occasions about how damned fine the fonts looked on my
desktop and how (from those who knew) how well the OSS community had
done with the AA stuff.  I was actually amazed at how often Mac users
would comment about how nice my fonts looked.  (Kudos to Owen and team
on this!)


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From leonard at den.ottolander.nl  Sun Jul 24 10:47:40 2005
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Sun, 24 Jul 2005 12:47:40 +0200
Subject: [Fwd: Midnight Commander 4.6.1 has been released.]
Message-ID: <1122202059.5758.2.camel@athlon.localdomain>

Hi all,

I'm very pleased to announce to you that it finally happened: The long
awaited midnight commander version 4.6.1 has finally been released!
Enjoy.

Leonard.

-----Forwarded Message-----
From: Miguel de Icaza <miguel at novell.com>
To: mc at gnome.org, mc-devel at gnome.org
Subject: Midnight Commander 4.6.1 has been released.
Date: Sat, 23 Jul 2005 13:22:17 -0400

Hello,

    A new version of Midnight Commander, an easy to use console-based
file manager for Unix systems has been released, it is available from:

http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/mc-4.6.1.tar.gz

	md5sum: 18b20db6e40480a53bac2870c56fc3c4  mc-4.6.1.tar.gz

    The changes since the last public release (4.6.0) are as follows:

- Core functionality.
	- Fix double free in mc_maybe_editor_or_viewer().
	- Do not blindly cleanup in exit_subshell().
	- Fix blocking of panel cd-ing with white space command.
	- Fix mini status after first Ctrl-O.
	- Fix dynamic loading of Photon library for shift keys.
	- Fix X11 connection handling.
	- Improve support for tcsh.
	- Use 8bit input as default.
	- Better support for '@' in FTP usernames.
	- Better large file support (int -> off_t)
	- Add gnome, rxvt and xterm-new terminals (keyword copy for mc.lib).
	- Make the find dialog more responsive while scanning through large
	  files.
	- Add implementation to cons.handler for FreeBSD 4.x and 5.x.
	- Screen saving is now supported on FreeBSD console.
	- Hide temporary commands from history.
	- Add --with-glib12 option to configure to force using glib 1.2.x.
	- Add --disable-background option to disable background support.
	- Background support now uses pipes instead of UNIX sockets.
	- libX11 is loaded dynamically using gmodule if possible.
	- User is warned if one mc is run from another.
	- In red dialog boxes draw the hotkey characters with a color
	  different than the one used to paint the dialog.


- Security.
	- Fix CAN-2004-0226 (buffer overflows).
	- Fix CAN-2004-0231 (unsafe temporary file and directory creation).
	- Fix CAN-2004-0232 (format string vulnerablities).
	- cons.saver does not need to be setuid-root on Linux.
	- Hiding of FTP passwords.

- Portability.
	- Added configuration files for Sun Solaris pkgmk(1).
	- PC port has been removed.
	- Support for SCO UNIX has been removed.
	- Improve support for QNX Neutrino.

- Editor.
	- Fix position save bug.
	- Improve c.syntax.
	- Improve makefile.syntax.
	- Improve python.syntax.
	- Improve eiffel.syntax.
	- Improve syntax.syntax.
	- Add syntax file for the x86 assembler.
	- Add syntax file for the Vision(tm) Ray Tracer.
	- Add syntax file for the CORBA IDL.
	- Add syntax file for the LUA programming language.
	- Fix bugs for mcedit compiled with ncurses.
	- New status string format in mcedit.
	- Support for large syntax files.
	- Temporarily disable safe save and backups on remote VFS because it
	  doesn't work.
	- Enable user menu in mcedit.
	- Add syntax file for the ASP.NET technology.
	- Add syntax file for the Eiffel programming language.
	- Add syntax file for the Ruby programming language.
	- Add syntax file for the C# programming language.
	- Upgrade php.syntax file.
	- Improve sql.syntax file.
	- Improve perl.syntax.
	- Improve diff.syntax.
	- Improve makefile.syntax.
	- Add "define" keyword for syntax files.

- Viewer.
	- Add .7z archives extensions to mc.ext.in.
	- Add OpenOffice.org 2 extensions to mc.ext.in.
	- Recognize both .udeb and .deb as Debian packages.


- VFS.
	- Extensive samba cleanup.
	- Fix possible crash on broken cpio archives.
	- Quote fixes in urar.in.
	- Full audit of quoting of parameters in vfs scripts (CAN-2004-0494).
	- Fixed CAN-2003-1023 (stack overflow in vfs_s_resolve_symlink).
	- Various fixes in tar.c.
	- VFS supports iso9660 images.
	- extfs/rpm: Don't show the package's contents directly in the root
	  directory, but only as an archive called contents.cpio.

- Screen libraries.
	Backport S-Lang fixes from HEAD.
	- Add many boundary check into internal slang library.
	- Internal slang upgrade to 1.4.9.
	- Increased maximum screen size to 512 x 512.
	- Add support for qansi-m terminals.


 

_______________________________________________
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
-- 
mount -t life -o ro /dev/dna /genetic/research




From buildsys at redhat.com  Sun Jul 24 11:21:00 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 24 Jul 2005 07:21:00 -0400
Subject: rawhide report: 20050724 changes
Message-ID: <200507241121.j6OBL0VU030288@porkchop.devel.redhat.com>

 

 
Updated Packages:

kernel-2.6.12-1.1436_FC5
------------------------
* Sat Jul 23 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git5

* Mon Jul 18 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git4

openoffice.org-1:1.9.120-2.2.0.fc5
----------------------------------
* Sat Jul 23 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.120-2
- try and reenable ppc building

Broken deps for i386
----------------------------------------------------------
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)



Broken deps for ia64
----------------------------------------------------------
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)



Broken deps for ppc64
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config



Broken deps for ppc
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219



Broken deps for s390
----------------------------------------------------------
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	jonas - 4.3.3-1jpp_5fc.noarch requires carol = 0:1.8.9.3
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10





From mike at miketc.com  Sun Jul 24 15:11:59 2005
From: mike at miketc.com (Mike Chambers)
Date: Sun, 24 Jul 2005 10:11:59 -0500
Subject: Firefox 1.1 changed to 1.5
Message-ID: <1122217919.6385.6.camel@scrappy.miketc.com>

How does this affect the current 1.1 releases in rawhide and what is
expected now?  Will there be 1.5 releases now?

-- 
Mike Chambers
Madisonville, KY

"Everything is always harder, before it's easier!



From ovidiu at linux360.ro  Sun Jul 24 15:52:55 2005
From: ovidiu at linux360.ro (Ovidiu Lixandru)
Date: Sun, 24 Jul 2005 18:52:55 +0300
Subject: [Fwd: Midnight Commander 4.6.1 has been released.]
In-Reply-To: <1122202059.5758.2.camel@athlon.localdomain>
References: <1122202059.5758.2.camel@athlon.localdomain>
Message-ID: <42E3B957.9010008@linux360.ro>

Leonard den Ottolander wrote:
> Hi all,
> 
> I'm very pleased to announce to you that it finally happened: The long
> awaited midnight commander version 4.6.1 has finally been released!
> Enjoy.

So where's the news? :) We've been enjoying it for a while now.

[ovidiu at ovidiu ~]$ rpm -qi mc
Name        : mc                           Relocations: (not relocatable)
Version     : 4.6.1                             Vendor: Red Hat, Inc.
Release     : 0.14.FC3                      Build Date: Thu 21 Apr 2005 
10:15:19 AM EEST
Install Date: Fri 22 Apr 2005 07:50:06 PM EEST      Build Host: 
porky.build.redhat.com
Group       : System Environment/Shells     Source RPM: 
mc-4.6.1-0.14.FC3.src.rpm
Size        : 4848590                          License: GPL
Signature   : DSA/SHA1, Thu 21 Apr 2005 04:56:29 PM EEST, Key ID 
b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.ibiblio.org/mc/
Summary     : A user-friendly file manager and visual shell.
Description :
Midnight Commander is a visual shell much like a file manager, only
with many more features. It is a text mode application, but it also
includes mouse support if you are running GPM. Midnight Commander's
best features are its ability to FTP, view tar and zip files, and to
poke into RPMs for specific files.


-- 
Ovidiu Lixandru
linux360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050724/943bed0e/attachment.bin>

From caillon at redhat.com  Sun Jul 24 15:56:56 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sun, 24 Jul 2005 11:56:56 -0400
Subject: Firefox 1.1 changed to 1.5
In-Reply-To: <1122217919.6385.6.camel@scrappy.miketc.com>
References: <1122217919.6385.6.camel@scrappy.miketc.com>
Message-ID: <42E3BA48.3030502@redhat.com>

Mike Chambers wrote:
> How does this affect the current 1.1 releases in rawhide and what is
> expected now?  Will there be 1.5 releases now?

Well, upstream has not released anything since the announcement of a 1.5 appeared on slashdot.  I have a vivid imagination, but it does not create releases that don't exist.  ;-)



From nutello at sweetness.com  Sun Jul 24 16:12:24 2005
From: nutello at sweetness.com (Rudi Chiarito)
Date: Sun, 24 Jul 2005 18:12:24 +0200
Subject: Rawhide updates & Fonts
In-Reply-To: <604aa79105072314275bf3724c@mail.gmail.com>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<42E2A662.7050406@redhat.com>
	<1122150943.4269.4.camel@scrappy.miketc.com>
	<42E2AB31.2060003@redhat.com>
	<1122153829.3070.7.camel@localhost.localdomain>
	<604aa79105072314275bf3724c@mail.gmail.com>
Message-ID: <20050724161224.GD12143@plain.rackshack.net>

On Sat, Jul 23, 2005 at 05:27:16PM -0400, Jeff Spaleta wrote:
> Its very hard to talk about rendering issues unless we build up a
> flipbook of screencaptures that show the differences between different
> package builds in a standardized way.  I suffer from the same

I either was the original poster complaining about font rendering or I
replied to the original poster. I was going to answer to your request
for a screenshot when I would have had access to my Rawhide system
again, at the end of the day, but I was satisfied with Owen's reply, so
I didn't produce any screenshots. Plus, I don't use standard fonts, so
my report would have been not so easy to reproduce.

Anyway, I took the last screenshot I had for the system, dating back to
August 28th 2003, and compared it to today's Rawhide. I am not sure what
was in Rawhide on that day, but you can see some differences. You can of
course point out that pretty much every package on the system has
changed between the two screenshots. Heck, even the browser is not
exactly the same: Mozilla vs Firefox. Same for the themes used.

The image with the screenshots side-by-side can be found at
http://yax.uberh4x0r.org/cairoatemyfancyfonts.png (you probably want to
look at it on an LCD screen because of subpixel rendering)  

On the left, the desktop before Cairo. On the right, the desktop after
Cairo. Compare for example the text "Applications". 

The first difference I notice with Cairo is that subpixel smoothing for
LCD screens is never applied, no matter what the settings. Second, text
seems to look smaller now, probably because Cairo seems to ignore the
DPI settings. Even making the default size one point larger to
compensate for the difference, the text rendering quality is not as
good as it was. Third, some sort of hinting seems be always at work,
again ignoring the font preferences. With the font I use, ITC Officina
Serif, rendering is much better when no hinting is applied.

Look at the "T" in "Telescope" on the right. Or look at the "9" in "87
of 96 comments". It's horrible. At lower point sizes, it gets even worse
and it becomes barely distinguishable from a 0. I really noticed this
while doing online shopping. What was actually a price of $199.95 looked
to me as $100.05 instead. Thankfully, I noticed something funny with the
rendered text before I placed any orders under the impression of having
found a real bargain. ;)

I know that this is Rawhide after all and that the Cairo/GTK folks are
aware of the issues involved. So I won't be complaining again until
FC5t1 is 304 weeks away.

What you say seems to call for some program that can automate the task
of rendering parts of the GUI in a reproduceable fashion, in order to
spot any regressions. Does anything like that exist? It would be nice to
have such a tool. Ideally, it would be fed Glade files or something
along those lines. It took me way too long to doctor that image in the
GIMP, it should rather be a matter of minutes or even seconds. 

-- 
Rudi



From leonard at den.ottolander.nl  Sun Jul 24 18:33:01 2005
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Sun, 24 Jul 2005 20:33:01 +0200
Subject: [Fwd: Midnight Commander 4.6.1 has been released.]
In-Reply-To: <42E3B957.9010008@linux360.ro>
References: <1122202059.5758.2.camel@athlon.localdomain>
	<42E3B957.9010008@linux360.ro>
Message-ID: <1122229981.5758.128.camel@athlon.localdomain>

Hi Ovidiu,

On Sun, 2005-07-24 at 17:52, Ovidiu Lixandru wrote:
> > I'm very pleased to announce to you that it finally happened: The long
> > awaited midnight commander version 4.6.1 has finally been released!
> > Enjoy.
> 
> So where's the news? :) We've been enjoying it for a while now.
> 
> [ovidiu at ovidiu ~]$ rpm -qi mc
> Name        : mc                           Relocations: (not relocatable)
> Version     : 4.6.1                             Vendor: Red Hat, Inc.
> Release     : 0.14.FC3                      Build Date: Thu 21 Apr 2005 

Mind the 0 in the release number. FC3 rpms are built from pre release
tarballs. Not that much difference, but still :) .

Anyway, with an official release we hope to see a lot of legacy users
move to the new version. I know this is not the FC Legacy list, but felt
like announcing it here anyway.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research




From bernie at develer.com  Sun Jul 24 23:16:19 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Mon, 25 Jul 2005 01:16:19 +0200
Subject: dbus-qt
Message-ID: <42E42143.8060109@develer.com>

Hello,

the dbus-qt package disappeared a few months ago, altough
Qt bindings in the upstream version appear to be well
maintained and healty.

Without dbus-qt, HAL support can't be enabled in KDE,
which makes volume management somewhat broken.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From arjanv at redhat.com  Sat Jul 23 11:10:48 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 23 Jul 2005 07:10:48 -0400
Subject: fonts
In-Reply-To: <1122116272.6845.2.camel@localhost.localdomain>
References: <1122116272.6845.2.camel@localhost.localdomain>
Message-ID: <1122117048.3582.9.camel@localhost.localdomain>

On Sat, 2005-07-23 at 16:27 +0530, divij bhatt wrote:
> Hi,
>     I am using Fedora core 2 I want to know that how can I install a
> particular font into the system.

then you're mailing the wrong mailinglist and should mail
fedora-list at redhat.com instead. This mailinglist is about the
development of fedora not about end user help.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050723/df325adc/attachment.sig>

From rdieter at math.unl.edu  Mon Jul 25 03:32:55 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 24 Jul 2005 22:32:55 -0500
Subject: dbus-qt
In-Reply-To: <1110043263.2451.35.camel@localhost.localdomain>
References: <200503051737.02475.ml-fedora@fathomssen.de>
	<1110043263.2451.35.camel@localhost.localdomain>
Message-ID: <42E45D67.8020702@math.unl.edu>

John (J5) Palmieri wrote:
> On Sat, 2005-03-05 at 11:37, Frederick Alexander Thomssen wrote:

>>once dbus-qt was removed from fedora because there was no use for it. but now 
>>kde 3.4 supports dbus-qt for the media:/ protocol which indicated if a new 
>>device was connected. so there now is a use for dbus-qt so i think it ought 
>>to be included.
> 
> 
> Does an app in fedora core require it? 

k3b (v0.12+), at least, can use it, if available.

-- Rex



From rodd at clarkson.id.au  Mon Jul 25 03:33:41 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 25 Jul 2005 13:33:41 +1000
Subject: Firefox scroll bar background 'cracking'
Message-ID: <1122262421.3688.30.camel@localhost.localdomain>

Hey, this is really trivial, but I've noticed on recent versions of
Firefox (deerpark) that if I scroll up or down quickly, then the
background of the scroll bar area gets lines in it.

You can best see this by scrolling up or down using the scroll wheel,
and then keeping your mouse out of the scroll bar area.

I can't grab a screenshot of this as the print screen tool seems to
refresh the window before grabbing it (which can be quite annoying for
getting screen shots of these sorts of things where the toolkit seems to
be 'fracturing' the output.

Are others seeing this, and is it worth bugzillaring?


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From buildsys at redhat.com  Mon Jul 25 11:14:55 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 25 Jul 2005 07:14:55 -0400
Subject: rawhide report: 20050725 changes
Message-ID: <200507251114.j6PBEth6013383@porkchop.devel.redhat.com>

 

 
Updated Packages:

elfutils-0.110-1
----------------
* Sun Jul 24 2005 Roland McGrath <roland at redhat.com> - 0.110-1
- update to 0.110

glibc-2.3.90-6
--------------
* Mon Jul 25 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-6
- update from CVS
  - fix execvp if PATH is not in environment and the call is going
    to fail (BZ#1125)
  - another bits/wchar2.h fix (#163990)

jonas-0:4.3.3-1jpp_6fc
----------------------
* Fri Jul 22 2005 Gary Benson <gbenson at redhat.com> - 4.3.3-1jpp_6fc
- Don't ship the mammoth and pointless client.jar.
- Rebuild to pick up jta from geronimo-specs.

memtest86+-1.60-1
-----------------
* Wed Jun 29 2005 Warren Togami <wtogami at redhat.com. - 1.60-1
- 1.60

nfs-utils-1.0.7-10
------------------
* Fri Jul 15 2005 Steve Dickson <SteveD at RedHat.com> 1.0.7-9
- Add ctlbits patch that introduced the -N -T and -U
  command line flags to rpc.nfsd.

* Thu Jun 16 2005 Steve Dickson <SteveD at RedHat.com> 1.0.7-9
- Removed the chkconfig-ing of rpcsvcgssd since the  
  init script will bring the daemon up and down (bz 160570)

pcmciautils-007-1
-----------------
* Sun Jul 24 2005 Bill Nottingham <notting at redhat.com> 007-1
- further udev-related tweaks (#163311)
udev-063-2
----------
* Sun Jul 24 2005 Bill Nottingham <notting at redhat.com> - 063-2
- don't set SEQNUM for scsi replay events (#163729)

xpdf-1:3.00-21
--------------
* Mon Jul 25 2005 Than Ngo <than at redhat.com> 3.00-21
- fix xpdf crash #163807

Broken deps for i386
----------------------------------------------------------
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	eclipse-platform - 1:3.1.0_fc-6.i386 requires ant-jmf
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	eclipse-platform - 1:3.1.0_fc-6.x86_64 requires ant-jmf
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	eclipse-platform - 1:3.1.0_fc-6.ppc requires ant-jmf
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390
----------------------------------------------------------
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21



Broken deps for ppc64
----------------------------------------------------------
	firstboot - 1.3.43-1.noarch requires system-config-display
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)



Broken deps for s390x
----------------------------------------------------------
	selinux-policy-targeted-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	selinux-policy-strict - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	selinux-policy-strict-sources - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	selinux-policy-targeted - 1.25.3-3.noarch requires kernel >= 0:2.6.11-1.1219





From nicolas.mailhot at laposte.net  Mon Jul 25 11:29:32 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 25 Jul 2005 13:29:32 +0200 (CEST)
Subject: Firefox scroll bar background 'cracking'
In-Reply-To: <1122262421.3688.30.camel@localhost.localdomain>
References: <1122262421.3688.30.camel@localhost.localdomain>
Message-ID: <42059.192.54.193.37.1122290972.squirrel@rousalka.dyndns.org>


On Lun 25 juillet 2005 05:33, Rodd Clarkson wrote:
> Hey, this is really trivial, but I've noticed on recent versions of
> Firefox (deerpark) that if I scroll up or down quickly, then the
> background of the scroll bar area gets lines in it.

I see this too now and then.

-- 
Nicolas Mailhot



From rodd at clarkson.id.au  Mon Jul 25 12:11:26 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 25 Jul 2005 22:11:26 +1000
Subject: CPU has 8 scaling options, but only 5 are offered.
Message-ID: <1122293486.2915.8.camel@localhost.localdomain>

I've got a Centrino laptop with a 2.0GHz CPU running at 533 FSB.

'cat /proc/cpuinfo' shows:

[rodd at localhost ~]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 2.00GHz
stepping        : 8
cpu MHz         : 798.092
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips        : 1598.35

Stepping seems to suggest that the CPU can scale through 8 step, but the
GNOME CPU frequency selector only offers 5 steps (800, 1.07, 1.33, 1.6
and 2.0) and not 8.

Why is this (and should I bugzilla it)?



Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From fedora at camperquake.de  Mon Jul 25 12:16:34 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 25 Jul 2005 14:16:34 +0200
Subject: CPU has 8 scaling options, but only 5 are offered.
In-Reply-To: <1122293486.2915.8.camel@localhost.localdomain>
References: <1122293486.2915.8.camel@localhost.localdomain>
Message-ID: <20050725141634.153f0dde@nausicaa.camperquake.de>

Hi.

Rodd Clarkson <rodd at clarkson.id.au> wrote:

> Stepping seems to suggest that the CPU can scale through 8 step, but the
> GNOME CPU frequency selector only offers 5 steps (800, 1.07, 1.33, 1.6
> and 2.0) and not 8.

Stepping is a kind of model number for the mask used to produce the processor.
It has nothing to do with scaling.

-- 
"Only wimps use tape backup: _real_ men just upload their important stuff 
on ftp, and let the rest of the world mirror it ;)"
  -- Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi



From shiva at sewingwitch.com  Mon Jul 25 21:41:32 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Mon, 25 Jul 2005 14:41:32 -0700
Subject: GUI Debugger
Message-ID: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>

What yum or rpm invocation do I need to use to discover what GUI debuggers 
are available in Fedora? I'm working on an OpenGL-based game so a 
curses-based debugger would probably be best, but I can run the app 
windowed so an X-based debugger would also be useful. Mostly I'm looking 
for something that can show me source lines, the current call stack, the 
local variables, and watched variables. I tried yum install for insight and 
ddd but it didn't find those.



From dcbw at redhat.com  Mon Jul 25 21:48:17 2005
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 25 Jul 2005 17:48:17 -0400
Subject: GUI Debugger
In-Reply-To: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
Message-ID: <1122328097.19561.59.camel@dcbw.boston.redhat.com>

On Mon, 2005-07-25 at 14:41 -0700, Kenneth Porter wrote:
> What yum or rpm invocation do I need to use to discover what GUI debuggers 
> are available in Fedora? I'm working on an OpenGL-based game so a 
> curses-based debugger would probably be best, but I can run the app 
> windowed so an X-based debugger would also be useful. Mostly I'm looking 
> for something that can show me source lines, the current call stack, the 
> local variables, and watched variables. I tried yum install for insight and 
> ddd but it didn't find those.

hmm, ddd has been in Fedora since forever...  Its definitely in Core.

dcbw> yum search ddd
Searching Packages:
Setting up repositories
Reading repository metadata in from local files


ddd.i386                                 3.3.11-1               development
Matched from:
ddd
The Data Display Debugger (DDD) is a popular GUI for command-line
debuggers like GDB, DBX, JDB, WDB, XDB, the Perl debugger, and the
...



From mlauterbach at mail.wtamu.edu  Mon Jul 25 21:52:28 2005
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Mon, 25 Jul 2005 16:52:28 -0500
Subject: GUI Debugger
Message-ID: <6B7915142ED1EE42B27715B1D8CBBAFE3381F6@WTVS1.wtacademic.wtamu.edu>

On Monday, July 25, 2005 4:48 PM, Dan Williams wrote:
> On Mon, 2005-07-25 at 14:41 -0700, Kenneth Porter wrote:
> > What yum or rpm invocation do I need to use to discover 
> what GUI debuggers 
> > are available in Fedora? I'm working on an OpenGL-based game so a 
> > curses-based debugger would probably be best, but I can run the app 
> > windowed so an X-based debugger would also be useful. 
> Mostly I'm looking 
> > for something that can show me source lines, the current 
> call stack, the 
> > local variables, and watched variables. I tried yum install 
> for insight and 
> > ddd but it didn't find those.
> 
> hmm, ddd has been in Fedora since forever...  Its definitely in Core.
> 
> dcbw> yum search ddd
> Searching Packages:
> Setting up repositories
> Reading repository metadata in from local files
> 
> 
> ddd.i386                                 3.3.11-1             
>   development

...and you don't need the development tree to get it.  ddd-3.3.10-2 is
available in the "base" repo for FC4.

Matthew E. Lauterbach
West Texas A&M University  



From dmalcolm at redhat.com  Mon Jul 25 22:09:09 2005
From: dmalcolm at redhat.com (David Malcolm)
Date: Mon, 25 Jul 2005 18:09:09 -0400
Subject: GUI Debugger
In-Reply-To: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
Message-ID: <1122329350.29074.0.camel@cassandra.boston.redhat.com>

On Mon, 2005-07-25 at 14:41 -0700, Kenneth Porter wrote:
> What yum or rpm invocation do I need to use to discover what GUI debuggers 
> are available in Fedora? I'm working on an OpenGL-based game so a 
> curses-based debugger would probably be best, but I can run the app 
> windowed so an X-based debugger would also be useful. Mostly I'm looking 
> for something that can show me source lines, the current call stack, the 
> local variables, and watched variables. I tried yum install for insight and 
> ddd but it didn't find those.
> 

If running FC-4 you might want to try eclipse-cdt



From rstrode at redhat.com  Tue Jul 26 00:42:59 2005
From: rstrode at redhat.com (Ray Strode)
Date: Mon, 25 Jul 2005 20:42:59 -0400
Subject: GUI Debugger
In-Reply-To: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
Message-ID: <1122338579.3259.3.camel@localhost.localdomain>

Hi,
> What yum or rpm invocation do I need to use to discover what GUI debuggers 
> are available in Fedora? I'm working on an OpenGL-based game so a 
> curses-based debugger would probably be best, 
One little hidden secret of gdb builds from the last six months or so is
the "layout" command.  Type layout at the (gdb) prompt and you'll see a
source window come up.  There are a few other windows, too.  help layout
lists them i believe.

ctrl-x a

closes the window

-- 
Ray Strode <rstrode at redhat.com>



From bernie at develer.com  Tue Jul 26 01:00:18 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Tue, 26 Jul 2005 03:00:18 +0200
Subject: dbus-qt
In-Reply-To: <42E45D67.8020702@math.unl.edu>
References: <200503051737.02475.ml-fedora@fathomssen.de>	<1110043263.2451.35.camel@localhost.localdomain>
	<42E45D67.8020702@math.unl.edu>
Message-ID: <42E58B22.8070806@develer.com>

Rex Dieter wrote:
> John (J5) Palmieri wrote:
> 
>> On Sat, 2005-03-05 at 11:37, Frederick Alexander Thomssen wrote:
> 
> 
>>> once dbus-qt was removed from fedora because there was no use for it.
>>> but now kde 3.4 supports dbus-qt for the media:/ protocol which
>>> indicated if a new device was connected. so there now is a use for
>>> dbus-qt so i think it ought to be included.
>>
>> Does an app in fedora core require it? 
> 
> k3b (v0.12+), at least, can use it, if available.

For the record, I've hacked dbus.spec to re-enable
Qt support, updating references to Qt 3.1 to 3.3).

The resulting dbus-qt subpackage builds and installs
correctly.  KDE builds fine against it with a small
configury patch to look for libraries in /usr/lib64
on x86_64.

Now I can use media:/ in Konqueror.  Looks like a
safe change for fedora-devel.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From buildsys at redhat.com  Tue Jul 26 11:26:31 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 26 Jul 2005 07:26:31 -0400
Subject: rawhide report: 20050726 changes
Message-ID: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>

 

 
Updated Packages:

eclipse-1:3.1.0_fc-10
---------------------
* Mon Jul 25 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-10
- Change mozilla BuildRequirement to be equals and not greater-than or equals
  since we need the exact version for our patches.
- Bump mozilla requirements and patches to 1.7.10.
- Bump release due to FC4 update still not being released.
- Add ant-jmf to exclude list.

* Tue Jul 19 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-7
- Remove ant-jmf symlinking and requirement.
- Update to use java-gcj-compat and not java-1.4.2-gcj-compat.

* Tue Jul 12 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-6
- Bump release to build against new gcc.
- Bump gcc requirement to gcc 4.0.1.
- Add back BuildArch until we get bootstrapping sorted out.
- Bump required version of java-gcj-compat to the latest (-40jpp_37rh).
- Remove lots of jiggery-pokery with native compilation and use gbenson's new
  aot-compile.
- Re-work files sections appropriately.
- Change mozilla-nspr-devel -> nspr-devel due to change in mozilla packaging.
- Update patch for mozilla build as per above.
- Add org.eclipse.osgi_3.1.0.jar to exclude.

evolution-2.3.5.1-1
-------------------
* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-1
- 2.3.5.1
- Update evo_major from 2.2 to 2.4
- Updated evo-calendar-print-with-pango- patch from version 4 to 5
- Removed Patch105: evolution-2.2.2-fix-new-mail-notify.patch as configure.in
  in this branch tests for existance for dbus-glib-1, rather than max-version.
- Removed Patch801: gb-309138-attach-48417-fix-evo-conduit-memleaks.patch as
  this is now in upstream tarball.
- Removed evolution-calendar-importers and evolution-addressbook-importers
  directories.
- Updated evolution-2.2.2-no-gnome-common.patch to include a patch to rename
  mozilla-nspr to nspr

evolution-data-server-1.3.5-2
-----------------------------
* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 1.3.5-2
- Added patch to use nspr rather than mozilla-nspr when doing pkg-config tests
  (Patch5: evolution-data-server-1.3.5-nspr_fix.patch)

* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 1.3.5-1
- 1.3.5
- Split eds_major (was 1.2) into eds_base_version (1.4) and eds_api_version
  (1.2) to correspond to BASE_VERSION and API_VERSION in configure.in; updated
  rest of specfile accordingly.
- Removed upstreamed patch: 
  evolution-data-server-1.2.0-cope-with-a-macro-called-read.patch

evolution-webcal-2.3.90-1
-------------------------
* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.90-1
- 2.3.90

fontconfig-2.3.2-1
------------------
* Fri Jul 22 2005 Kristian H??gsberg <krh at redhat.com> - 2.3.2-1
- Update to fontconfig-2.3.2.  Drop

	fontconfig-2.1-slighthint.patch,
	fontconfig-2.2.3-timestamp.patch,
	fontconfig-2.2.3-names.patch,
	fontconfig-2.2.3-ta-pa-orth.patch, and
	fontconfig-2.2.3-timestamp.patch,

  as they are now merged upstream.

- Fold fontconfig-2.2.3-add-sazanami.patch into
  fontconfig-2.3.2-defaultconfig.patch and split rules to disable CJK
  hinting out into /etc/fonts/conf.d/50-no-hint-fonts.conf.

- Drop fontconfig-0.0.1.020826.1330-blacklist.patch and use the new
  rejectfont directive to reject those fonts in 40-blacklist-fonts.conf.

- Add fontconfig-2.3.2-only-parse-conf-files.patch to avoid parsing
  .rpmsave files.

- Renable s390 documentation now that #97079 has been fixed and add
  BuildRequires: for docbook-utils and docbook-utils-pdf.

- Drop code to iconv and custom install man pages, upstream does the
  right thing now.

- Add workaround from hell to make elinks cooperate so we can build
  txt documentation.

gdb-6.3.0.0-1.53
----------------
* Mon Jul 25 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.53
- Bump up release number.

* Mon Jul 25 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.50
- Fix bug with info frame and cursor address on ia64.
- Add testcase to verify pseudo-registers calculated for ia64 sigtramp.
- Bugzilla 160339

glib2-2.7.4-1
-------------
* Fri Jul 22 2005 Matthias Clasen <mclasen at redhat.com> - 2.7.4-1
- Update to 2.7.4

grub-0.95-15
------------
* Mon Jul 25 2005 Peter Jones <pjones at redhat.com> 0.95-15
- Make "grub-install --recheck" warn the user about how bad it is,
  and keep a backup file, which it reverts to upon detecting some errors.

* Wed Jul 06 2005 Peter Jones <pjones at redhat.com> 0.95-14
- Fix changelog to be UTF-8

gtkhtml3-3.7.5-2
----------------
* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 3.7.5-2
- update gtkhtml_major from 3.6 to 3.8

* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 3.7.5-1
- 3.7.5

hplip-0.9.4-2
-------------
* Mon Jul 25 2005 Tim Waugh <twaugh at redhat.com> 0.9.4-2
- Use 'condrestart' not 'restart' in %post scriptlet.

kernel-2.6.12-1.1437_FC5
------------------------
* Mon Jul 25 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git7

libgal2-2:2.5.3-1
-----------------
* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 2:2.5.3-1
- 2.5.3
- Update gal-major from 2.4 to 2.6
- Fir gtk-doc subdirectory from gal-2.6 to gal

libsepol-1.7.5-2
----------------
* Mon Jul 25 2005 Dan Walsh <dwalsh at redhat.com> 1.7.5-2
- Fix unitialized variable problem

logwatch-6.1.2-3
----------------
* Mon Jul 25 2005 Ivana Varekova <varekova at redhat.com> 6.1.2-3
- bug 162689 - add noreplace option

mc-1:4.6.1a-0.12
----------------
* Mon Jul 25 2005 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.12
- new mc release 4.6.1
- sync extensions patch
- fix several gcc4 signedness warnings

openoffice.org-1:1.9.117-3.1.0.fc4
----------------------------------
* Tue Jul 19 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-3
- add workspace.qwizardsbfooo20.patch to avoid missing FormWizard spam
on save

* Fri Jul 15 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-2
- add openoffice.org-1.9.117.ooo52023.evoadb2.nognuconst.patch to
  fix evoab2
- add openoffice.org-1.9.117.ooo52048.inhalt.sw.patch as minor .doc
  export regression fix for rh#158252#
- split email mailmerge stuff into a subpackage to avoid python
  dependancy on writer

* Wed Jul 13 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-1
- bump to next version and drop the integrated (finally) fpicker patch
- back to using stlport for now because I'm dubious
- rh#162984# fallbacks from en_AU to en_GB for wizards
- rh#160783# set a targetname for font when it's found
- add openoffice.org-1.9.117.rh163147.thorndale.fontconfig.patch
- add openoffice.org-1.9.117.ooo51912.nullpointer.wizards.patch for
  rh#161173#

openoffice.org-1:1.9.121-1.2.0.fc5
----------------------------------
* Mon Jul 25 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.121-1
- next version

* Sat Jul 23 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.120-3
- add openoffice.org-1.9.120.rh158977.execshield.bridges.patch
- workaround gcj accessor problem on a global basis

pam-0.80-4
----------
* Tue Jul 26 2005 Tomas Mraz <tmraz at redhat.com> 0.80-4
- fix 64bit bug in pam_pwdb
- don't crash in pam_unix if pam_get_data fail

rpm-4.4.2-1
-----------
* Thu Jul 21 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.2-1
- Upgrade to upstream release

* Tue May 24 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.1-21
- Update translations (#154623)

* Sat May 21 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.1-20
- Drop signature patch
- dangling unpackaged symlinks

selinux-policy-strict-1.25.3-5
------------------------------
* Mon Jul 25 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-5
- Fix cyrus

* Thu Jul 21 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-4
- Bump for FC4

selinux-policy-targeted-1.25.3-5
--------------------------------
* Mon Jul 25 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-5
- Fix cyrus

* Thu Jul 21 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-4
- Bump for FC4

system-config-bind-4.0.0-20_FC5
-------------------------------
* Mon Jul 25 2005 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-20_FC5
- fix bug 164129: DNS.py 'declartation' -> 'declaration'
- fix bug 163937: NamedConfOptions 'Name of ke.' -> 'Name of key.'
- fix bug 158438: avoid sentence splitting in translatable messages

* Fri Jul 15 2005 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-18_FC5
- fix bug 163304: handle empty contents in Zone.out
- fix bug 161988: create links to .mo files for bindconf
- fix bug 161987: don't use substring of translated string in DNSsec TrustedKeys
- fix bug 159534: add descriptions to deprecated record types
- fix bug 158441: shorten NamedConfOptions description strings

* Sun May 08 2005 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-16_FC5
- fix bug 157207:  allow build to succeed if bind package is not installed

xmlto-0.0.18-7
--------------
* Mon Jul 25 2005 Tim Waugh <twaugh at redhat.com> 0.0.18-7
- Rebuild for new man-pages stylesheet.

* Mon Apr 04 2005 Tim Waugh <twaugh at redhat.com>
- Requires util-linux and flex, as does the build.

yaboot-1.3.13-0.1
-----------------
* Fri Jul 22 2005 Paul Nasrat <pnasrat at redhat.com> - 1.3.13-0.1
- Upstream 1.3.13
- Add patches on yaboot-1.3.x tree
- Try dropping ppc64 initrd patch

Broken deps for i386
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-panel - 2.11.4-2.i386 requires libecal-1.2.so.2
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	gnome-panel - 2.11.4-2.x86_64 requires libecal-1.2.so.2()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit)
	gnome-panel - 2.11.4-2.ia64 requires libecal-1.2.so.2()(64bit)



Broken deps for s390
----------------------------------------------------------
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	gnome-panel - 2.11.4-2.s390 requires libecal-1.2.so.2
	selinux-policy-targeted-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	selinux-policy-targeted - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	selinux-policy-strict - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219



Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnome-panel - 2.11.4-2.ppc requires libecal-1.2.so.2
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3



Broken deps for ppc64
----------------------------------------------------------
	firstboot - 1.3.43-1.noarch requires system-config-display
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)



Broken deps for s390x
----------------------------------------------------------
	evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit)
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	gnome-panel - 2.11.4-2.s390x requires libecal-1.2.so.2()(64bit)
	selinux-policy-targeted - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.1-1.s390 requires kernel >= 0:2.2.0
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	selinux-policy-strict - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14
	selinux-policy-targeted-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	libpcap - 14:0.9.1-1.s390x requires kernel >= 0:2.2.0
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)





From tarjei.knapstad at predichem.com  Tue Jul 26 11:33:18 2005
From: tarjei.knapstad at predichem.com (Tarjei Knapstad)
Date: Tue, 26 Jul 2005 13:33:18 +0200
Subject: GUI Debugger
In-Reply-To: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
Message-ID: <1122377597.12276.1.camel@tarjei.predichem.nett>

On Mon, 2005-07-25 at 23:41, Kenneth Porter wrote:
> What yum or rpm invocation do I need to use to discover what GUI debuggers 
> are available in Fedora? I'm working on an OpenGL-based game so a 
> curses-based debugger would probably be best, but I can run the app 
> windowed so an X-based debugger would also be useful. Mostly I'm looking 
> for something that can show me source lines, the current call stack, the 
> local variables, and watched variables. I tried yum install for insight and 
> ddd but it didn't find those.

It's quite a bit more than you ask for, but I'd highly recommend you
give KDevelop a spin. It has gdb, valgrind, cvs, subversion, younameit
integrated.

--
Tarjei



From rodd at clarkson.id.au  Tue Jul 26 11:46:49 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 26 Jul 2005 21:46:49 +1000
Subject: rawhide report: 20050726 changes
In-Reply-To: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
Message-ID: <1122378409.22994.1.camel@localhost.localdomain>

On Tue, 2005-07-26 at 07:26 -0400, Build System wrote:

> openoffice.org-1:1.9.117-3.1.0.fc4
> ----------------------------------
> * Tue Jul 19 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-3
> - add workspace.qwizardsbfooo20.patch to avoid missing FormWizard spam
> on save
> 
> * Fri Jul 15 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-2
> - add openoffice.org-1.9.117.ooo52023.evoadb2.nognuconst.patch to
>   fix evoab2
> - add openoffice.org-1.9.117.ooo52048.inhalt.sw.patch as minor .doc
>   export regression fix for rh#158252#
> - split email mailmerge stuff into a subpackage to avoid python
>   dependancy on writer
> 
> * Wed Jul 13 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-1
> - bump to next version and drop the integrated (finally) fpicker patch
> - back to using stlport for now because I'm dubious
> - rh#162984# fallbacks from en_AU to en_GB for wizards
> - rh#160783# set a targetname for font when it's found
> - add openoffice.org-1.9.117.rh163147.thorndale.fontconfig.patch
> - add openoffice.org-1.9.117.ooo51912.nullpointer.wizards.patch for
>   rh#161173#
> 
> openoffice.org-1:1.9.121-1.2.0.fc5
> ----------------------------------
> * Mon Jul 25 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.121-1
> - next version
> 
> * Sat Jul 23 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.120-3
> - add openoffice.org-1.9.120.rh158977.execshield.bridges.patch
> - workaround gcj accessor problem on a global basis

Caillon,  you have been busy.  I'm guessing the FC4 version slipped in
accidently?


-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From caolanm at redhat.com  Tue Jul 26 12:17:50 2005
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 26 Jul 2005 13:17:50 +0100
Subject: rawhide report: 20050726 changes
In-Reply-To: <1122378409.22994.1.camel@localhost.localdomain>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
	<1122378409.22994.1.camel@localhost.localdomain>
Message-ID: <1122380270.2765.6.camel@localhost.localdomain>

On Tue, 2005-07-26 at 21:46 +1000, Rodd Clarkson wrote:
> On Tue, 2005-07-26 at 07:26 -0400, Build System wrote:
> 
> > openoffice.org-1:1.9.117-3.1.0.fc4
> > ----------------------------------

> > 
> > openoffice.org-1:1.9.121-1.2.0.fc5
> > ----------------------------------

> Caillon,  you have been busy.  I'm guessing the FC4 version slipped in
> accidently?

I've no idea why the FC4 update showed up in the rawhide report email as
well as the actual seperate rawhide update. It's all done automatically.
Unless I did something particularly dumb I doubt there's anything to
worry about.

C.

btw: caillon is redhat mozilla/firefox maintainer Christopher Aillon,
not me :-)




From steve at rueb.com  Tue Jul 26 14:09:45 2005
From: steve at rueb.com (Steve Bergman)
Date: Tue, 26 Jul 2005 09:09:45 -0500
Subject: How much is known about -Os on X86_64?
Message-ID: <42E64429.1070308@rueb.com>

I have a few questions.  How much work has been done to benchmark the 
advantages/disadvantages of using -Os for various FC packages on 
X86_64?  I know that on x86 -Os is used fort he kernel.  On X86_64, it 
looks to me like -Os is not used.  In fact, it seems that I read 
somewhere that one should not use -Os on X86_64, or shouldn't use it on 
the kernel, or shouldn't use it in FC4, or something like that and I 
can't seem to relocate that reference.  Anyone know anything about that?

Also, how useful would it be if  did some real world benchmarking on my 
Athlon64 2800+ system running FC4/X86_64?  Would I be wasting my time, 
duplicating someone else's previous efforts?  What packages might 
benefit?  Is it possible that compilintg the whole distro -Os might be a 
win? (Intuitively, it seems that everything being a little smaller could 
have a cummulative effect on the speed of the whole system, saving disk 
reads, main memory, cache memory, etc.)

I'm no expert at this stuff, so I figured asking on the list before I do 
much work would be a good idea.  Searches of the archives don't seem to 
turn up much except that "-Os can sometimes help".

So far, I've just played around a little bit with bzip2.  -Os seems to 
be a pretty good win for bzip2 compression, giving over about a 12% 
improvement.

Thank you for any input.

-Steve Bergman



From caillon at redhat.com  Tue Jul 26 14:25:48 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 26 Jul 2005 10:25:48 -0400
Subject: rawhide report: 20050726 changes
In-Reply-To: <1122378409.22994.1.camel@localhost.localdomain>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
	<1122378409.22994.1.camel@localhost.localdomain>
Message-ID: <42E647EC.7020500@redhat.com>

On 07/26/2005 07:46 AM, Rodd Clarkson wrote:

>On Tue, 2005-07-26 at 07:26 -0400, Build System wrote:
>
>  
>
>>openoffice.org-1:1.9.117-3.1.0.fc4
>>----------------------------------
>>* Tue Jul 19 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-3
>>- add workspace.qwizardsbfooo20.patch to avoid missing FormWizard spam
>>on save
>>
>>* Fri Jul 15 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-2
>>- add openoffice.org-1.9.117.ooo52023.evoadb2.nognuconst.patch to
>>  fix evoab2
>>- add openoffice.org-1.9.117.ooo52048.inhalt.sw.patch as minor .doc
>>  export regression fix for rh#158252#
>>- split email mailmerge stuff into a subpackage to avoid python
>>  dependancy on writer
>>
>>* Wed Jul 13 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-1
>>- bump to next version and drop the integrated (finally) fpicker patch
>>- back to using stlport for now because I'm dubious
>>- rh#162984# fallbacks from en_AU to en_GB for wizards
>>- rh#160783# set a targetname for font when it's found
>>- add openoffice.org-1.9.117.rh163147.thorndale.fontconfig.patch
>>- add openoffice.org-1.9.117.ooo51912.nullpointer.wizards.patch for
>>  rh#161173#
>>
>>openoffice.org-1:1.9.121-1.2.0.fc5
>>----------------------------------
>>* Mon Jul 25 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.121-1
>>- next version
>>
>>* Sat Jul 23 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.120-3
>>- add openoffice.org-1.9.120.rh158977.execshield.bridges.patch
>>- workaround gcj accessor problem on a global basis
>>    
>>
>
>Caillon,  you have been busy.  I'm guessing the FC4 version slipped in
>accidently?
>
Yesterday was my day off.  Try again.  :-)



From wcohen at redhat.com  Tue Jul 26 15:34:09 2005
From: wcohen at redhat.com (William Cohen)
Date: Tue, 26 Jul 2005 11:34:09 -0400
Subject: How much is known about -Os on X86_64?
In-Reply-To: <42E64429.1070308@rueb.com>
References: <42E64429.1070308@rueb.com>
Message-ID: <42E657F1.8080502@redhat.com>

Steve Bergman wrote:
> I have a few questions.  How much work has been done to benchmark the 
> advantages/disadvantages of using -Os for various FC packages on 
> X86_64?  I know that on x86 -Os is used fort he kernel.  On X86_64, it 
> looks to me like -Os is not used.  In fact, it seems that I read 
> somewhere that one should not use -Os on X86_64, or shouldn't use it on 
> the kernel, or shouldn't use it in FC4, or something like that and I 
> can't seem to relocate that reference.  Anyone know anything about that?
> 
> Also, how useful would it be if  did some real world benchmarking on my 
> Athlon64 2800+ system running FC4/X86_64?  Would I be wasting my time, 
> duplicating someone else's previous efforts?  What packages might 
> benefit?  Is it possible that compilintg the whole distro -Os might be a 
> win? (Intuitively, it seems that everything being a little smaller could 
> have a cummulative effect on the speed of the whole system, saving disk 
> reads, main memory, cache memory, etc.)
> 
> I'm no expert at this stuff, so I figured asking on the list before I do 
> much work would be a good idea.  Searches of the archives don't seem to 
> turn up much except that "-Os can sometimes help".
> 
> So far, I've just played around a little bit with bzip2.  -Os seems to 
> be a pretty good win for bzip2 compression, giving over about a 12% 
> improvement.
> 
> Thank you for any input.
> 
> -Steve Bergman
> 

None of the stuff I know of hasn't looked at x86_64.
You might look at the Code-Size Benchmark Environment (CSiBE):

http://www.inf.u-szeged.hu/csibe/

However, they do not seem to be running the tests for x86_64 at this time.


During the fall of 2004 a couple of students at North Carolina State 
University did some experiments compiling mozilla and the related 
libraries with -Os on x86 machines to see the effect. They found that 
there was some reduction in size and startup time.

http://people.redhat.com/wcohen/ncsu2004/Space Optimizations.pdf


-Will



From notting at redhat.com  Tue Jul 26 16:23:51 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 26 Jul 2005 12:23:51 -0400
Subject: rawhide report: 20050726 changes
In-Reply-To: <1122380270.2765.6.camel@localhost.localdomain>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
	<1122378409.22994.1.camel@localhost.localdomain>
	<1122380270.2765.6.camel@localhost.localdomain>
Message-ID: <20050726162351.GB18875@nostromo.devel.redhat.com>

Caolan McNamara (caolanm at redhat.com) said: 
> I've no idea why the FC4 update showed up in the rawhide report email as
> well as the actual seperate rawhide update. It's all done automatically.
> Unless I did something particularly dumb I doubt there's anything to
> worry about.

PPC. It pulled the last built one for ppc, which happened to be the
FC4 update.

Bill



From caolanm at redhat.com  Tue Jul 26 16:40:35 2005
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 26 Jul 2005 17:40:35 +0100
Subject: rawhide report: 20050726 changes
In-Reply-To: <20050726162351.GB18875@nostromo.devel.redhat.com>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
	<1122378409.22994.1.camel@localhost.localdomain>
	<1122380270.2765.6.camel@localhost.localdomain>
	<20050726162351.GB18875@nostromo.devel.redhat.com>
Message-ID: <1122396036.2765.15.camel@localhost.localdomain>

On Tue, 2005-07-26 at 12:23 -0400, Bill Nottingham wrote:
> Caolan McNamara (caolanm at redhat.com) said: 
> > I've no idea why the FC4 update showed up in the rawhide report email as
> > well as the actual seperate rawhide update. It's all done automatically.
> > Unless I did something particularly dumb I doubt there's anything to
> > worry about.
> 
> PPC. It pulled the last built one for ppc, which happened to be the
> FC4 update.

aha, indeed the OOo ppc builds are suspended until gcc#17828# is fixed.

C.



From jakub at redhat.com  Tue Jul 26 16:49:57 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 26 Jul 2005 12:49:57 -0400
Subject: rawhide report: 20050726 changes
In-Reply-To: <1122396036.2765.15.camel@localhost.localdomain>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
	<1122378409.22994.1.camel@localhost.localdomain>
	<1122380270.2765.6.camel@localhost.localdomain>
	<20050726162351.GB18875@nostromo.devel.redhat.com>
	<1122396036.2765.15.camel@localhost.localdomain>
Message-ID: <20050726164957.GK30077@devserv.devel.redhat.com>

On Tue, Jul 26, 2005 at 05:40:35PM +0100, Caolan McNamara wrote:
> On Tue, 2005-07-26 at 12:23 -0400, Bill Nottingham wrote:
> > Caolan McNamara (caolanm at redhat.com) said: 
> > > I've no idea why the FC4 update showed up in the rawhide report email as
> > > well as the actual seperate rawhide update. It's all done automatically.
> > > Unless I did something particularly dumb I doubt there's anything to
> > > worry about.
> > 
> > PPC. It pulled the last built one for ppc, which happened to be the
> > FC4 update.
> 
> aha, indeed the OOo ppc builds are suspended until gcc#17828# is fixed.

I have a patch, but it needs more work and ten times more testing
afterwards.  It will almost surely break Darwin, AIX, ppc xcoff targets
or some other weirdo ppc{,64} setup.

	Jakub



From seandarcy2 at gmail.com  Tue Jul 26 19:11:32 2005
From: seandarcy2 at gmail.com (sean)
Date: Tue, 26 Jul 2005 15:11:32 -0400
Subject: radeonfb kernel switch no longer works?
Message-ID: <dc61t5$tf3$1@sea.gmane.org>

On amd64 with radeon 8500, dmesg:


Bootdata ok (command line is root=/dev/hda5 
video=radeonfb:1024x768-32 at 100)
Linux version 2.6.12-1.1437_FC5 
(bhcompile at crowe.devel.redhat.com) (gcc version 4.0.1 
20050720 (Red Hat 4.0.1-4)) #1 SMP Mon
Jul 25 18:21:05 EDT 2005
.............

This used to give console output at 1024x768. Even a couple 
of weeks ago, maybe. Now I get a vga display.

Have the kernel switches changed?

sean



From bernie at develer.com  Tue Jul 26 20:06:09 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Tue, 26 Jul 2005 22:06:09 +0200
Subject: rawhide report: 20050726 changes
In-Reply-To: <20050726164957.GK30077@devserv.devel.redhat.com>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>	<1122378409.22994.1.camel@localhost.localdomain>	<1122380270.2765.6.camel@localhost.localdomain>	<20050726162351.GB18875@nostromo.devel.redhat.com>	<1122396036.2765.15.camel@localhost.localdomain>
	<20050726164957.GK30077@devserv.devel.redhat.com>
Message-ID: <42E697B1.6010306@develer.com>

Jakub Jelinek wrote:

>>aha, indeed the OOo ppc builds are suspended until gcc#17828# is fixed.
> 
> I have a patch, but it needs more work and ten times more testing
> afterwards.  It will almost surely break Darwin, AIX, ppc xcoff targets
> or some other weirdo ppc{,64} setup.

By the way, why does the x86_64 distribution use an i386 OOo
package?

I'm sure it's been decided for a good reason, but I'm curious.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From rdieter at math.unl.edu  Tue Jul 26 20:11:05 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 26 Jul 2005 15:11:05 -0500
Subject: rawhide report: 20050726 changes
In-Reply-To: <42E697B1.6010306@develer.com>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>	<1122378409.22994.1.camel@localhost.localdomain>	<1122380270.2765.6.camel@localhost.localdomain>	<20050726162351.GB18875@nostromo.devel.redhat.com>	<1122396036.2765.15.camel@localhost.localdomain>	<20050726164957.GK30077@devserv.devel.redhat.com>
	<42E697B1.6010306@develer.com>
Message-ID: <dc65cq$7r0$1@sea.gmane.org>

Bernardo Innocenti wrote:
> Jakub Jelinek wrote:
> 
> 
>>>aha, indeed the OOo ppc builds are suspended until gcc#17828# is fixed.
>>
>>I have a patch, but it needs more work and ten times more testing
>>afterwards.  It will almost surely break Darwin, AIX, ppc xcoff targets
>>or some other weirdo ppc{,64} setup.
> 
> 
> By the way, why does the x86_64 distribution use an i386 OOo
> package?

Maily because OOo doesn't build (natively) on x86_64?  (-:

-- Rex



From bernie at develer.com  Tue Jul 26 20:13:26 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Tue, 26 Jul 2005 22:13:26 +0200
Subject: Firefox binary plugins on x86_64
Message-ID: <42E69966.6000606@develer.com>

Hello,

somehow Firefox in SuSE 9.3 supports 32bit plugins on x86_64.

The firefox-bin executable is really a 64bit binary, and
I couldn't guess how they did it by examining the files
in the binary package.

Could we do something similar in Fedora?  If needed, I'm
volunteering to dissect SuSE's SRPM to extract the patch.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From shiva at sewingwitch.com  Tue Jul 26 20:27:43 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 26 Jul 2005 13:27:43 -0700
Subject: GUI Debugger
In-Reply-To: <1122377597.12276.1.camel@tarjei.predichem.nett>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
Message-ID: <49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>

--On Tuesday, July 26, 2005 1:33 PM +0200 Tarjei Knapstad 
<tarjei.knapstad at predichem.com> wrote:

> It's quite a bit more than you ask for, but I'd highly recommend you
> give KDevelop a spin. It has gdb, valgrind, cvs, subversion, younameit
> integrated.

I'll give it a shot. I feared it might be a bit much to set up, as I mostly 
use the command line.

Do any of the GUI front-ends for gdb have something like a local variables 
window? Looking at gdbtui, I just see source lines and registers. While I'm 
not afraid of looking at assembler, I'd like to look at source language 
variables (C++) if I can.




From warren at togami.com  Tue Jul 26 20:33:06 2005
From: warren at togami.com (Warren Togami)
Date: Tue, 26 Jul 2005 10:33:06 -1000
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E69966.6000606@develer.com>
References: <42E69966.6000606@develer.com>
Message-ID: <42E69E02.5060607@togami.com>

Bernardo Innocenti wrote:
> Hello,
> 
> somehow Firefox in SuSE 9.3 supports 32bit plugins on x86_64.
>

Which plugins?  Some plugins like mozplugger have a separate native 
binary plugin, and that runs a separate process for the media.  If it is 
running a separate process then that is one possible explanation of how 
they did it.

> The firefox-bin executable is really a 64bit binary, and
> I couldn't guess how they did it by examining the files
> in the binary package.
> 
> Could we do something similar in Fedora?  If needed, I'm
> volunteering to dissect SuSE's SRPM to extract the patch.
> 

If you could post URLs to their .src.rpm that would be handy.

Warren Togami
wtogami at redhat.com



From shiva at sewingwitch.com  Tue Jul 26 21:01:12 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 26 Jul 2005 14:01:12 -0700
Subject: Bugzilla down 20050726 1400 PDT
Message-ID: <49B82281A77C01FDED46A384@[10.169.6.233]>

Getting the dreaded "500 Internal server error" when fetching 
<https://bugzilla.redhat.com/bugzilla/index.cgi>.



From notting at redhat.com  Tue Jul 26 21:08:33 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 26 Jul 2005 17:08:33 -0400
Subject: Bugzilla down 20050726 1400 PDT
In-Reply-To: <49B82281A77C01FDED46A384@[10.169.6.233]>
References: <49B82281A77C01FDED46A384@[10.169.6.233]>
Message-ID: <20050726210833.GA20669@nostromo.devel.redhat.com>

Kenneth Porter (shiva at sewingwitch.com) said: 
> Getting the dreaded "500 Internal server error" when fetching 
> <https://bugzilla.redhat.com/bugzilla/index.cgi>.

Yup, it's known. Being investigated.

Bill



From rodd at clarkson.id.au  Tue Jul 26 21:20:33 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 27 Jul 2005 07:20:33 +1000
Subject: rawhide report: 20050726 changes
In-Reply-To: <42E647EC.7020500@redhat.com>
References: <200507261126.j6QBQV5u001463@porkchop.devel.redhat.com>
	<1122378409.22994.1.camel@localhost.localdomain>
	<42E647EC.7020500@redhat.com>
Message-ID: <1122412833.2942.4.camel@localhost.localdomain>

On Tue, 2005-07-26 at 10:25 -0400, Christopher Aillon wrote:
> On 07/26/2005 07:46 AM, Rodd Clarkson wrote:
> 
> >On Tue, 2005-07-26 at 07:26 -0400, Build System wrote:
> >
> >  
> >
> >>openoffice.org-1:1.9.117-3.1.0.fc4
> >>----------------------------------
> >>* Tue Jul 19 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.117-3
<snip>
> >>
> >>openoffice.org-1:1.9.121-1.2.0.fc5
> >>----------------------------------
> >>* Mon Jul 25 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.121-1
> >>- next version
<snip>
> >
> >Caillon,  you have been busy.  I'm guessing the FC4 version slipped in
> >accidently?
> >
> Yesterday was my day off.  Try again.  :-)

My humblest apologies gentlemen.  I now realize that Caillon and Caolan
are two different people.  (whoops)

Caolan, thanks for your great work on OpenOffice.org
Caillan, thanks for your great work on Firefox.

This is actually something of a relief because I was stunned that one
people would be handling both OOo and Firefox/Mozilla/etc, both which
seem to be big tasks in themselves.


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From caillon at redhat.com  Wed Jul 27 04:11:55 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 27 Jul 2005 00:11:55 -0400
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E69966.6000606@develer.com>
References: <42E69966.6000606@develer.com>
Message-ID: <42E7098B.9060109@redhat.com>

Bernardo Innocenti wrote:
> Hello,
> 
> somehow Firefox in SuSE 9.3 supports 32bit plugins on x86_64.
> 
> The firefox-bin executable is really a 64bit binary, and
> I couldn't guess how they did it by examining the files
> in the binary package.
> 
> Could we do something similar in Fedora?  If needed, I'm
> volunteering to dissect SuSE's SRPM to extract the patch.
> 

Hi,

I just spoke to Wolfgang Rosenauer at SuSE (maintainer of their firefox package) who says you're mistaken.  SuSE ships both the 32 and 64 bit versions of the browser on x86-64 precisely for this problem, which I'm pretty sure we do as well.



From notting at redhat.com  Wed Jul 27 04:16:29 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 27 Jul 2005 00:16:29 -0400
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E7098B.9060109@redhat.com>
References: <42E69966.6000606@develer.com> <42E7098B.9060109@redhat.com>
Message-ID: <20050727041629.GC26422@nostromo.devel.redhat.com>

Christopher Aillon (caillon at redhat.com) said: 
> SuSE ships both the 32 and 64 bit 
> versions of the browser on x86-64 precisely for this problem, which I'm 
> pretty sure we do as well.

No, we don't.

Bill



From caillon at redhat.com  Wed Jul 27 04:22:01 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 27 Jul 2005 00:22:01 -0400
Subject: Firefox binary plugins on x86_64
In-Reply-To: <20050727041629.GC26422@nostromo.devel.redhat.com>
References: <42E69966.6000606@develer.com> <42E7098B.9060109@redhat.com>
	<20050727041629.GC26422@nostromo.devel.redhat.com>
Message-ID: <42E70BE9.8080700@redhat.com>

Bill Nottingham wrote:
> Christopher Aillon (caillon at redhat.com) said: 
> 
>>SuSE ships both the 32 and 64 bit 
>>versions of the browser on x86-64 precisely for this problem, which I'm 
>>pretty sure we do as well.
> 
> 
> No, we don't.

Why not?  We used to at some point in the not-too-distant past or my memory is failing me at my old age.  :-(



From notting at redhat.com  Wed Jul 27 05:05:40 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 27 Jul 2005 01:05:40 -0400
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E70BE9.8080700@redhat.com>
References: <42E69966.6000606@develer.com> <42E7098B.9060109@redhat.com>
	<20050727041629.GC26422@nostromo.devel.redhat.com>
	<42E70BE9.8080700@redhat.com>
Message-ID: <20050727050540.GA26583@nostromo.devel.redhat.com>

Christopher Aillon (caillon at redhat.com) said: 
> >>SuSE ships both the 32 and 64 bit 
> >>versions of the browser on x86-64 precisely for this problem, which I'm 
> >>pretty sure we do as well.
>
> >No, we don't.
> 
> Why not?

No particularly good way to set a sane preference for which browser
you'd want to launch when, among other things.

> We used to at some point in the not-too-distant past or my memory 
> is failing me at my old age.  :-(

At one point, 32-bit moz was pulled in on x86-64 due to an OOo dep.

Bill



From dragoran at feuerpokemon.de  Wed Jul 27 05:35:51 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 27 Jul 2005 07:35:51 +0200
Subject: missing dep in last update?
Message-ID: <42E71D37.1090901@feuerpokemon.de>

Tryed to run yum update today and got:
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package libcddb.x86_64 0:1.1.0-1.fc4 set to be updated
---> Package gnome-panel.x86_64 0:2.10.1-10.2 set to be updated
---> Package system-config-printer-gui.x86_64 0:0.6.131.3-1 set to be 
updated
---> Package system-config-printer.x86_64 0:0.6.131.3-1 set to be updated
---> Package gnome-panel-devel.x86_64 0:2.10.1-10.2 set to be updated
--> Running transaction check
--> Processing Dependency: libcddb.so.0()(64bit) for package: libcdio
--> Finished Dependency Resolution
Error: Missing Dependency: libcddb.so.0()(64bit) is needed by package 
libcdio
but:
locate libcddb.so
/usr/lib64/libcddb.so.0
/usr/lib64/libcddb.so.0.1.2
file /usr/lib64/libcddb.so.0.1.2
/usr/lib64/libcddb.so.0.1.2: ELF 64-bit LSB shared object, AMD x86-64, 
version 1 (SYSV), stripped
rpm -qf /usr/lib64/libcddb.so.0
libcddb-1.0.2-2
is this a bug in some of the packages or a yum bug?



From wtogami at redhat.com  Wed Jul 27 05:40:16 2005
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 26 Jul 2005 19:40:16 -1000
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E70BE9.8080700@redhat.com>
References: <42E69966.6000606@develer.com>
	<42E7098B.9060109@redhat.com>	<20050727041629.GC26422@nostromo.devel.redhat.com>
	<42E70BE9.8080700@redhat.com>
Message-ID: <42E71E40.8010403@redhat.com>

Christopher Aillon wrote:
> Bill Nottingham wrote:
> 
>> Christopher Aillon (caillon at redhat.com) said:
>>
>>> SuSE ships both the 32 and 64 bit versions of the browser on x86-64 
>>> precisely for this problem, which I'm pretty sure we do as well.
>>
>>
>>
>> No, we don't.
> 
> 
> Why not?  We used to at some point in the not-too-distant past or my 
> memory is failing me at my old age.  :-(
> 

With FC4+, aside from the conflicting /usr/bin/firefox script, it is 
now impossible to even uninstall the 64bit firefox and install the 32bit 
firefox due to the multilib bonoboectomy.  Doing this has been 
problematic in the past when it was possible during FC3, because 
whenever there is another firefox security update, it would blow away 
the 32bit version and install the new 64bit version.

Warren Togami
wtogami at redhat.com



From dragoran at feuerpokemon.de  Wed Jul 27 05:58:50 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 27 Jul 2005 07:58:50 +0200
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E71E40.8010403@redhat.com>
References: <42E69966.6000606@develer.com>	<42E7098B.9060109@redhat.com>	<20050727041629.GC26422@nostromo.devel.redhat.com>	<42E70BE9.8080700@redhat.com>
	<42E71E40.8010403@redhat.com>
Message-ID: <42E7229A.206@feuerpokemon.de>

Warren Togami wrote:

> Christopher Aillon wrote:
>
>> Bill Nottingham wrote:
>>
>>> Christopher Aillon (caillon at redhat.com) said:
>>>
>>>> SuSE ships both the 32 and 64 bit versions of the browser on x86-64 
>>>> precisely for this problem, which I'm pretty sure we do as well.
>>>
>>>
>>>
>>>
>>> No, we don't.
>>
>>
>>
>> Why not?  We used to at some point in the not-too-distant past or my 
>> memory is failing me at my old age.  :-(
>>
>
> With FC4+, aside from the conflicting /usr/bin/firefox script, it is 
> now impossible to even uninstall the 64bit firefox and install the 
> 32bit firefox due to the multilib bonoboectomy.  Doing this has been 
> problematic in the past when it was possible during FC3, because 
> whenever there is another firefox security update, it would blow away 
> the 32bit version and install the new 64bit version.
>
> Warren Togami
> wtogami at redhat.com
>
I am running 32-bit firefox on fc4 x86_64 without any problems.
When there is a security update I just grab it from the i386 tree.



From tarjei.knapstad at predichem.com  Wed Jul 27 11:02:11 2005
From: tarjei.knapstad at predichem.com (Tarjei Knapstad)
Date: Wed, 27 Jul 2005 13:02:11 +0200
Subject: GUI Debugger
In-Reply-To: <49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
	<49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
Message-ID: <1122462131.12276.3.camel@tarjei.predichem.nett>

On Tue, 2005-07-26 at 22:27, Kenneth Porter wrote:
> --On Tuesday, July 26, 2005 1:33 PM +0200 Tarjei Knapstad 
> <tarjei.knapstad at predichem.com> wrote:
> 
> > It's quite a bit more than you ask for, but I'd highly recommend you
> > give KDevelop a spin. It has gdb, valgrind, cvs, subversion, younameit
> > integrated.
> 
> I'll give it a shot. I feared it might be a bit much to set up, as I mostly 
> use the command line.
> 
> Do any of the GUI front-ends for gdb have something like a local variables 
> window? Looking at gdbtui, I just see source lines and registers. While I'm 
> not afraid of looking at assembler, I'd like to look at source language 
> variables (C++) if I can.
> 

If you mean a window of watched variables and their current value, then
yes, KDevelop has this too :)

--
Tarjei




From buildsys at redhat.com  Wed Jul 27 11:20:59 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 27 Jul 2005 07:20:59 -0400
Subject: rawhide report: 20050727 changes
Message-ID: <200507271120.j6RBKxln002038@porkchop.devel.redhat.com>

 

 
Updated Packages:

diffstat-1.38-3
---------------
* Tue Jul 26 2005 Tim Waugh <twaugh at redhat.com> 1.38-3
- Fixed man page location (bug #164296).

distcache-1.4.5-9
-----------------
* Tue Jul 26 2005 Joe Orton <jorton at redhat.com> 1.4.5-9
- add epoch and release to devel->main dependency
- don't build static libraries

* Fri May 06 2005 Joe Orton <jorton at redhat.com> 1.4.5-8
- make libdistcache{,server} depend on libnal
- add scriplet requirements

foomatic-3.0.2-23
-----------------
* Tue Jul 26 2005 Tim Waugh <twaugh at redhat.com> 3.0.2-23
- Updated db to 3.0-20050726.
- No longer need ieee1284 patch.

* Mon Jul 25 2005 Tim Waugh <twaugh at redhat.com>
- Fix IEEE 1284 ID for HP Photosmart 7260 (bug #162915).

gdb-6.3.0.0-1.57
----------------
* Tue Jul 26 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.57
- Bump up release number.

* Tue Jul 26 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.54
- Add testcase to verify printing of inherited members
- Bugzilla 146835

gimp-2:2.2.8-1
--------------
* Mon Jul 25 2005 Nils Philippsen <nphilipp at redhat.com> - 2.2.8
- version 2.2.8
- clean up file list generation a bit
- gimptool manpage is in section 1 not 5
- list auto-generated .pyc and .pyo files

* Fri May 13 2005 Nils Philippsen <nphilipp at redhat.com>
- fix inline asm of MMX/SSE optimizations instead of using -mmmx and the like

* Fri May 13 2005 Nils Philippsen <nphilipp at redhat.com>
- fix cpuinstructionset patch so that it actually uses CPU-specific
  optimizations

gnome-panel-2.11.4-3
--------------------
* Tue Jul 26 2005 Mark McLoughlin <markmc at redhat.com> 2.11.4-3
- Rebuild

hplip-0.9.4-3
-------------
* Tue Jul 26 2005 Tim Waugh <twaugh at redhat.com> 0.9.4-3
- Fix condrestart in the initscript.

httpd-2.0.54-11
---------------
* Thu Jun 30 2005 Joe Orton <jorton at redhat.com> 2.0.54-11
- mod_dav_fs: fix uninitialized variable (#162144)
- add epoch to dependencies as appropriate
- mod_ssl: drop dependencies on dev, make
- mod_ssl: mark post script dependencies as such

kudzu-1.1.119-1
---------------
* Tue Jul 26 2005 Bill Nottingham <notting at redhat.com> 1.1.119-1
- make sure changing network devices are properly caught (#141338)

libwmf-0.2.8.3-9
----------------
* Tue Jul 26 2005 Caolan McNamara <caolanm at redhat.com> 0.2.8.3-9
- rh#154813# wmf upsidedown, spec (what of is there is) says that
  this shouldn't happen, but...

logrotate-3.7.1-14
------------------
* Tue Jul 26 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.1-14
- fix some "error running script" messages

* Tue Jul 26 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.1-13
- fix man page (#163458,#163366)

* Wed Jun 22 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.1-12
- enhance logrotate with "dateext", "maxage"

oprofile-0.9.1-2
----------------
* Tue Jul 19 2005 Will Cohen <wcohen at redhat.com>
- Rebase on OProfile 0.9.1.
- Add MIPS 24K files to manifest.

rarpd-ss981107-22
-----------------
* Tue Jul 26 2005 Phil Knirsch <pknirsch at redhat.com> ss981107-22
- Fixed and optimized loop with sprintf usage
- Added missing stdlib.h include

rpm-4.4.2-2
-----------
* Tue Jul 26 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.2-1
- popt minor version bump
- revert to perl.req/perl.prov for now

synaptics-0:0.14.3-2
--------------------
* Tue Jul 26 2005 Paul Nasrat <pnasrat at redhat.com> - 0:0.14.3-2
- Fix man page location (#164295)

system-config-securitylevel-1.6.0-1
-----------------------------------
* Tue Jul 26 2005 Chris Lumens <clumens at redhat.com> 1.6.0-1
- Convert UI to using glade instead of handwritten code.
- Lots of updated translations.

tar-1.15.1-7
------------
* Tue Jul 26 2005 Peter Vrabec <pvrabec at redhat.com> 1.15.1-7
- exclude listed02.at from testsuite

* Fri Jul 22 2005 Peter Vrabec <pvrabec at redhat.com> 1.15.1-6
- remove tar-1.14-err.patch, not needed (158743)

tcpdump-14:3.9.3-2
------------------
* Tue Jul 26 2005 Martin Stransky <stransky at redhat.com> - 14:3.9.3-2
- fixed typo in last patch

* Tue Jul 26 2005 Martin Stransky <stransky at redhat.com> - 14:3.9.3-1
- New upstream version - 3.9.3
- fix for #164227 (buffer overflow)
- fix for #164230 (missing debug info)

Broken deps for s390
----------------------------------------------------------
	evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3
	selinux-policy-strict-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	rpm - 4.4.2-2.s390 requires popt = 0:1.10.1
	ethereal - 0.10.11-4.s390 requires libpcap.so.0.9.1
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	selinux-policy-targeted - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10
	mod_ssl - 1:2.0.54-11.s390 requires httpd = 1:2.0.54-11
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	selinux-policy-targeted-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	ethereal-gnome - 0.10.11-4.s390 requires libpcap.so.0.9.1
	ppp - 2.4.3-2.1.s390 requires libpcap.so.0.9.1
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	selinux-policy-strict - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0



Broken deps for ppc
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	ethereal-gnome - 0.10.11-4.ppc requires libpcap.so.0.9.1
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	isdn4k-utils - 3.2-31.ppc requires libpcap.so.0.9.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.ppc requires libpcap.so.0.9.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.ppc requires libpcap.so.0.9.1
	mod_ssl - 1:2.0.54-11.ppc requires httpd = 1:2.0.54-11
	rpm - 4.4.2-2.ppc requires popt = 0:1.10.1



Broken deps for i386
----------------------------------------------------------
	ethereal - 0.10.11-4.i386 requires libpcap.so.0.9.1
	isdn4k-utils - 3.2-31.i386 requires libpcap.so.0.9.1
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	mod_ssl - 1:2.0.54-11.i386 requires httpd = 1:2.0.54-11
	rpm - 4.4.2-2.i386 requires popt = 0:1.10.1
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.i386 requires libpcap.so.0.9.1
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3



Broken deps for s390x
----------------------------------------------------------
	rpm - 4.4.2-2.s390x requires popt = 0:1.10.1
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	selinux-policy-targeted - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	selinux-policy-targeted-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	ethereal-gnome - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	selinux-policy-strict-sources - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	selinux-policy-strict - 1.25.3-5.noarch requires kernel >= 0:2.6.11-1.1219
	ethereal - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	ppp - 2.4.3-2.1.s390x requires libpcap.so.0.9.1()(64bit)
	mod_ssl - 1:2.0.54-11.s390x requires httpd = 1:2.0.54-11
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit)
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14



Broken deps for ia64
----------------------------------------------------------
	ethereal-gnome - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	mod_ssl - 1:2.0.54-11.ia64 requires httpd = 1:2.0.54-11
	ppp - 2.4.3-2.1.ia64 requires libpcap.so.0.9.1()(64bit)
	isdn4k-utils - 3.2-31.ia64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	rgmanager - 1.9.31-3.ia64 requires ccs
	evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	ethereal - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	rpm - 4.4.2-2.ia64 requires popt = 0:1.10.1



Broken deps for ppc64
----------------------------------------------------------
	ppp - 2.4.3-2.1.ppc64 requires libpcap.so.0.9.1()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	ethereal-gnome - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	ethereal - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	isdn4k-utils - 3.2-31.ppc64 requires libpcap.so.0.9.1()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	rpm - 4.4.2-2.ppc64 requires popt = 0:1.10.1
	mod_ssl - 1:2.0.54-11.ppc64 requires httpd = 1:2.0.54-11
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for x86_64
----------------------------------------------------------
	isdn4k-utils - 3.2-31.x86_64 requires libpcap.so.0.9.1()(64bit)
	mod_ssl - 1:2.0.54-11.x86_64 requires httpd = 1:2.0.54-11
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.x86_64 requires libpcap.so.0.9.1()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	rpm - 4.4.2-2.x86_64 requires popt = 0:1.10.1
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	ethereal-gnome - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit)
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5





From fedora at wir-sind-cool.org  Wed Jul 27 11:33:12 2005
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 27 Jul 2005 13:33:12 +0200
Subject: missing dep in last update?
In-Reply-To: <42E71D37.1090901@feuerpokemon.de>
References: <42E71D37.1090901@feuerpokemon.de>
Message-ID: <20050727133312.4a4bdc01.fedora@wir-sind-cool.org>

On Wed, 27 Jul 2005 07:35:51 +0200, dragoran wrote:

> Tryed to run yum update today and got:
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Package libcddb.x86_64 0:1.1.0-1.fc4 set to be updated
> ---> Package gnome-panel.x86_64 0:2.10.1-10.2 set to be updated
> ---> Package system-config-printer-gui.x86_64 0:0.6.131.3-1 set to be 
> updated
> ---> Package system-config-printer.x86_64 0:0.6.131.3-1 set to be updated
> ---> Package gnome-panel-devel.x86_64 0:2.10.1-10.2 set to be updated
> --> Running transaction check
> --> Processing Dependency: libcddb.so.0()(64bit) for package: libcdio
> --> Finished Dependency Resolution
> Error: Missing Dependency: libcddb.so.0()(64bit) is needed by package 
> libcdio
> but:
> locate libcddb.so
> /usr/lib64/libcddb.so.0
> /usr/lib64/libcddb.so.0.1.2
> file /usr/lib64/libcddb.so.0.1.2
> /usr/lib64/libcddb.so.0.1.2: ELF 64-bit LSB shared object, AMD x86-64, 
> version 1 (SYSV), stripped
> rpm -qf /usr/lib64/libcddb.so.0
> libcddb-1.0.2-2
> is this a bug in some of the packages or a yum bug?

It's a package bug in Fedora Extras. Known issue. It's in bugzilla already,
too.



From pnasrat at redhat.com  Wed Jul 27 12:25:01 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Wed, 27 Jul 2005 08:25:01 -0400
Subject: rpm/popt requiress Re: rawhide report: 20050727 changes
In-Reply-To: <200507271120.j6RBKxln002038@porkchop.devel.redhat.com>
References: <200507271120.j6RBKxln002038@porkchop.devel.redhat.com>
Message-ID: <1122467101.3516.1.camel@enki.eridu>


> Broken deps for s390
> ----------------------------------------------------------
> 	rpm - 4.4.2-2.s390 requires popt = 0:1.10.1


Already fixed will be in tomorrows rawhide.

Apologies for any inconvenience

Paul



From overholt at redhat.com  Wed Jul 27 13:38:27 2005
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 27 Jul 2005 09:38:27 -0400
Subject: GUI Debugger
In-Reply-To: <1122462131.12276.3.camel@tarjei.predichem.nett>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
	<49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
	<1122462131.12276.3.camel@tarjei.predichem.nett>
Message-ID: <20050727133827.GB1019@redhat.com>

* Tarjei Knapstad <tarjei.knapstad at predichem.com> [2005-07-27 07:02]:
> On Tue, 2005-07-26 at 22:27, Kenneth Porter wrote:
> > Do any of the GUI front-ends for gdb have something like a local variables 
> > window? Looking at gdbtui, I just see source lines and registers. While I'm 
> > not afraid of looking at assembler, I'd like to look at source language 
> > variables (C++) if I can.
> > 
> 
> If you mean a window of watched variables and their current value, then
> yes, KDevelop has this too :)

As does eclipse-cdt :)

Andrew



From zaitcev at redhat.com  Wed Jul 27 16:14:14 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 27 Jul 2005 09:14:14 -0700
Subject: Recent changes in the USB subsystem
In-Reply-To: <mailman.3428.1121860908.10239.fedora-devel-list@redhat.com>
References: <mailman.3428.1121860908.10239.fedora-devel-list@redhat.com>
Message-ID: <20050727091414.4397d7ce.zaitcev@redhat.com>

On Wed, 20 Jul 2005 14:00:02 +0200, Ralf Ertzinger <fedora at camperquake.de> wrote:

> Have there been changes to the kernel which may explain "lost"
> USB events? Or is it more probable that a mechanical failure
> has occured?

Everything is possible. How is 1.1436 doing?

-- Pete



From j.underwood at open.ac.uk  Wed Jul 27 16:20:31 2005
From: j.underwood at open.ac.uk (Jonathan Underwood)
Date: Wed, 27 Jul 2005 17:20:31 +0100
Subject: fedora extras mirror: Metadata file does not match checksum
Message-ID: <dc8c8f$r9l$1@sea.gmane.org>

Hi

I am consistently getting the following error from a fedora-extras 
mirror on running yum clean all && yum makecache

http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/repodata/primary.xml.gz: 
[Errno -1] Metadata file does not match checksum

However, I don't get the error message when I use
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basearch/

So, I was about to report the problem to the mirror provider, but I'm 
not entirely sure that's where the problem lies. Is there anyway I can 
gain more information on this problem?

[Apologies if this is the wrong list to ask this question on, I look on 
http://fedoraproject.org/wiki/Extras for a fedora-extras mailing list, 
but saw no reference to one.]

Thanks,
Jonathan.



From Nicolas.Mailhot at laPoste.net  Wed Jul 27 17:28:36 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 27 Jul 2005 19:28:36 +0200
Subject: Rawhide updates & Fonts
In-Reply-To: <1122149732.11316.0.camel@rousalka.dyndns.org>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<1122149732.11316.0.camel@rousalka.dyndns.org>
Message-ID: <1122485316.32580.11.camel@rousalka.dyndns.org>

Le samedi 23 juillet 2005 ? 22:15 +0200, Nicolas Mailhot a ?crit :
> Le samedi 23 juillet 2005 ? 19:42 +0000, Mike Chambers a ?crit :
> > With a fully updated FC4 + full rawhide updates, are the fonts still as
> > messed up as they have been recently, especially in evolution and
> > firefox (even with the alpha one?)?
> 
> Fonts are still messed a bit in Firefox (size). No complaints with Evo.

Well with fontconfig-2.3.2-1 OTOH rendering changed drastically

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050727/326a1646/attachment.sig>

From jspaleta at gmail.com  Wed Jul 27 19:28:05 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 27 Jul 2005 15:28:05 -0400
Subject: fedora extras mirror: Metadata file does not match checksum
In-Reply-To: <dc8c8f$r9l$1@sea.gmane.org>
References: <dc8c8f$r9l$1@sea.gmane.org>
Message-ID: <604aa7910507271228586bfcf4@mail.gmail.com>

On 7/27/05, Jonathan Underwood <j.underwood at open.ac.uk> wrote:
>http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/repodata/primary.xml.gz:
> [Errno -1] Metadata file does not match checksum

> However, I don't get the error message when I use
> baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basearch/
> 
> So, I was about to report the problem to the mirror provider, but I'm
> not entirely sure that's where the problem lies. Is there anyway I can
> gain more information on this problem?

The metadata associated with a repository is actually several files.
The list of metadata files for a repository is encoded in the file repomd.xml
which is cached on your system at /var/cache/yum/extras/repomd.xml.
This is the tiny file yum pulls first from the mirror to see if it
needs to pull any other metadata files from the mirror you are using.

repomd.xml essentially provides the mechanism that lets your local yum
client verify that the metadata files on the mirror form a
self-consistent set.  The repomd.xml file contains the sha1 sums that
yum uses. If you want to check by hand.. you download the
primary.xml.gz from the master server and from the mirror server.. run
sha1sum on both and compare those sums to the sha1sum of the
primary.xml.gz you have in your local yum cache. Compare the sums to
the sha1sum listed in repomd.xml that you have locally, on the master
server, and on the mirror server. From that matrix of sum comparisons,
you'll see where the problem lies.

If you contact a mirror while the mirror is processing updates from
the master server, you can run into situations where the repomd.xml
file is updated while primary.xml.gz has not been updated yet.. or
vice versa.  Or you could be having networking problems or filesystem
problems which are resulting in downloading an incomplete
primary.xml.gz.

-jef



From otaylor at redhat.com  Wed Jul 27 20:18:06 2005
From: otaylor at redhat.com (Owen Taylor)
Date: Wed, 27 Jul 2005 16:18:06 -0400
Subject: Rawhide updates & Fonts
In-Reply-To: <1122485316.32580.11.camel@rousalka.dyndns.org>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<1122149732.11316.0.camel@rousalka.dyndns.org>
	<1122485316.32580.11.camel@rousalka.dyndns.org>
Message-ID: <1122495486.17926.78.camel@localhost.localdomain>

On Wed, 2005-07-27 at 19:28 +0200, Nicolas Mailhot wrote:
> Le samedi 23 juillet 2005 ? 22:15 +0200, Nicolas Mailhot a ?crit :
> > Le samedi 23 juillet 2005 ? 19:42 +0000, Mike Chambers a ?crit :
> > > With a fully updated FC4 + full rawhide updates, are the fonts still as
> > > messed up as they have been recently, especially in evolution and
> > > firefox (even with the alpha one?)?
> > 
> > Fonts are still messed a bit in Firefox (size). No complaints with Evo.
> 
> Well with fontconfig-2.3.2-1 OTOH rendering changed drastically

How?

I expect no changes from that.

On the other hand, once we get the next set of Cairo/Pango/GTK+ changes
into the tree, rendering *will* change drastically ... in theory,
it will be identical to FC4 at that point.

						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050727/6d2687b3/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Wed Jul 27 20:38:58 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 27 Jul 2005 22:38:58 +0200
Subject: Rawhide updates & Fonts
In-Reply-To: <1122495486.17926.78.camel@localhost.localdomain>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<1122149732.11316.0.camel@rousalka.dyndns.org>
	<1122485316.32580.11.camel@rousalka.dyndns.org>
	<1122495486.17926.78.camel@localhost.localdomain>
Message-ID: <1122496739.1971.9.camel@rousalka.dyndns.org>

Le mercredi 27 juillet 2005 ? 16:18 -0400, Owen Taylor a ?crit :
> On Wed, 2005-07-27 at 19:28 +0200, Nicolas Mailhot wrote:
> > Le samedi 23 juillet 2005 ? 22:15 +0200, Nicolas Mailhot a ?crit :
> > > Le samedi 23 juillet 2005 ? 19:42 +0000, Mike Chambers a ?crit :
> > > > With a fully updated FC4 + full rawhide updates, are the fonts still as
> > > > messed up as they have been recently, especially in evolution and
> > > > firefox (even with the alpha one?)?
> > > 
> > > Fonts are still messed a bit in Firefox (size). No complaints with Evo.
> > 
> > Well with fontconfig-2.3.2-1 OTOH rendering changed drastically
> 
> How?
> 
> I expect no changes from that.
> 
> On the other hand, once we get the next set of Cairo/Pango/GTK+ changes
> into the tree, rendering *will* change drastically ... in theory,
> it will be identical to FC4 at that point.

Lines seem thinner, character spacing is degraded (some of them touch
when they didn't before). I'm sorry I can't be more specific, my eyes
are adapting and I don't have a pre-update control system to compare (so
I must try to remember a pre-yesterday system) but the changes were very
noticeable just after the rawhide sync. At least in evo, so maybe it's
evo-specific, but I seem to remember the Gnome panel changing too.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050727/291cd08e/attachment.sig>

From shiva at sewingwitch.com  Wed Jul 27 20:40:44 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 27 Jul 2005 13:40:44 -0700
Subject: GUI Debugger
In-Reply-To: <1122462131.12276.3.camel@tarjei.predichem.nett>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
	<49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
	<1122462131.12276.3.camel@tarjei.predichem.nett>
Message-ID: <18D1D305AFBE8BDCB1210D27@[192.168.5.135]>

--On Wednesday, July 27, 2005 1:02 PM +0200 Tarjei Knapstad 
<tarjei.knapstad at predichem.com> wrote:

> If you mean a window of watched variables and their current value, then
> yes, KDevelop has this too :)

Sort of. The Windows-hosted debuggers I'm familiar with (including 
DOS-hosted Borland Turbo Debug from 20 years ago) have two windows, watch 
and local. Watch includes a custom list of variables. Locals includes stuff 
in the current stack frame. Smarter debuggers can also walk the stack to 
display locals for different frames. There's a call stack window where one 
can select the frame of interest. This is very useful for answering "how 
did I get here?". A tree view of structures and arrays is another essential 
feature.

BTW, while discussing debuggers, do any of the high-end x86 family include 
the branch trace features commonly found in embedded processors? This is 
another handy way of figuring out how one got into a surprising section of 
code. Each branch is logged to special on-chip memory and the debugger uses 
this to reconstruct the sequence of instructions used to get to the current 
point. Before chips got really fast, this usually required an external ICE, 
but now with most code executing in internal cache, it's impossible to see 
what's happening from outside the chip. And because full trace is expensive 
in terms of chip real estate, only the branches are stored on-chip.



From danneye at rldcommunications.net  Wed Jul 27 21:16:08 2005
From: danneye at rldcommunications.net (DANEYE)
Date: Wed, 27 Jul 2005 23:16:08 +0200
Subject: No GRUB loading on a 2 HD system
Message-ID: <42B813B0005C43CA@pne-smtpout1-sn1.fre.skanova.net> (added by
	postmaster@pne.skanova.net)

Hi:

On my computer I have 2 HDs ?n 160Gb each.

On the primary (no partitions)  I have WXPPro installed and on

the slave (no partitions)  I have recently installed Fedora Core 4.

My problem is that the GRUB doesn?t ?act? so there is no

booting choice: I always end up with the XP.

There are no ?what I can see- tips and tricks to find about my problem

in the Hudson/Hudson/Ball/Duff Red Hat Fedora 4 UNLEASHED.

Anybody who has hints in the matter?

/dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050727/b90d615e/attachment.htm>

From otaylor at redhat.com  Wed Jul 27 21:47:50 2005
From: otaylor at redhat.com (Owen Taylor)
Date: Wed, 27 Jul 2005 17:47:50 -0400
Subject: Rawhide updates & Fonts
In-Reply-To: <1122496739.1971.9.camel@rousalka.dyndns.org>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<1122149732.11316.0.camel@rousalka.dyndns.org>
	<1122485316.32580.11.camel@rousalka.dyndns.org>
	<1122495486.17926.78.camel@localhost.localdomain>
	<1122496739.1971.9.camel@rousalka.dyndns.org>
Message-ID: <1122500870.17926.80.camel@localhost.localdomain>

On Wed, 2005-07-27 at 22:38 +0200, Nicolas Mailhot wrote:
> Le mercredi 27 juillet 2005 ? 16:18 -0400, Owen Taylor a ?crit :
> > On Wed, 2005-07-27 at 19:28 +0200, Nicolas Mailhot wrote:
> > > Le samedi 23 juillet 2005 ? 22:15 +0200, Nicolas Mailhot a ?crit :
> > > > Le samedi 23 juillet 2005 ? 19:42 +0000, Mike Chambers a ?crit :
> > > > > With a fully updated FC4 + full rawhide updates, are the fonts still as
> > > > > messed up as they have been recently, especially in evolution and
> > > > > firefox (even with the alpha one?)?
> > > > 
> > > > Fonts are still messed a bit in Firefox (size). No complaints with Evo.
> > > 
> > > Well with fontconfig-2.3.2-1 OTOH rendering changed drastically
> > 
> > How?
> > 
> > I expect no changes from that.
> > 
> > On the other hand, once we get the next set of Cairo/Pango/GTK+ changes
> > into the tree, rendering *will* change drastically ... in theory,
> > it will be identical to FC4 at that point.
> 
> Lines seem thinner, character spacing is degraded (some of them touch
> when they didn't before). I'm sorry I can't be more specific, my eyes
> are adapting and I don't have a pre-update control system to compare (so
> I must try to remember a pre-yesterday system) but the changes were very
> noticeable just after the rawhide sync. At least in evo, so maybe it's
> evo-specific, but I seem to remember the Gnome panel changing too.

I don't think this is a change with the fontconfig upgrade, but it is
the versus-FC4 delta that the next batch of upgrades should fix.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050727/adfdc5f9/attachment.sig>

From rodd at clarkson.id.au  Wed Jul 27 23:28:51 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Thu, 28 Jul 2005 09:28:51 +1000
Subject: Rawhide updates & Fonts
In-Reply-To: <1122496739.1971.9.camel@rousalka.dyndns.org>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<1122149732.11316.0.camel@rousalka.dyndns.org>
	<1122485316.32580.11.camel@rousalka.dyndns.org>
	<1122495486.17926.78.camel@localhost.localdomain>
	<1122496739.1971.9.camel@rousalka.dyndns.org>
Message-ID: <1122506931.3802.4.camel@localhost.localdomain>


> > > > Fonts are still messed a bit in Firefox (size). No complaints with Evo.
> > > 
> > > Well with fontconfig-2.3.2-1 OTOH rendering changed drastically
> > 
> > How?
> > 
> > I expect no changes from that.
> > 
> > On the other hand, once we get the next set of Cairo/Pango/GTK+ changes
> > into the tree, rendering *will* change drastically ... in theory,
> > it will be identical to FC4 at that point.
> 
> Lines seem thinner, character spacing is degraded (some of them touch
> when they didn't before). I'm sorry I can't be more specific, my eyes
> are adapting and I don't have a pre-update control system to compare (so
> I must try to remember a pre-yesterday system) but the changes were very
> noticeable just after the rawhide sync. At least in evo, so maybe it's
> evo-specific, but I seem to remember the Gnome panel changing too.

Ah, 20-20 hindsight is always so frustrating.

(and I know that we could just reinstall all the bits and pieces from
before this change, but....)

I'm beginning to wonder (now) whether it wouldn't have been a good idea
to have told people that changes were going to be made to the font
rendering system and in an attempt to make sure things 'look' right in
the future, could people take a screen shot of various applications they
use regularly so that there is actually something to compare 'now' and
'then'.

No real chance of doing it this time (unless people are willing to
reinstall or downgrade (would that even work?)) but might be worth
noting for next time (as I'm sure there will be a next time).


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From nmiell at comcast.net  Thu Jul 28 00:32:43 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Wed, 27 Jul 2005 17:32:43 -0700
Subject: GUI Debugger
In-Reply-To: <18D1D305AFBE8BDCB1210D27@[192.168.5.135]>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
	<49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
	<1122462131.12276.3.camel@tarjei.predichem.nett>
	<18D1D305AFBE8BDCB1210D27@[192.168.5.135]>
Message-ID: <1122510763.2833.4.camel@localhost.localdomain>

On Wed, 2005-07-27 at 13:40 -0700, Kenneth Porter wrote:

> BTW, while discussing debuggers, do any of the high-end x86 family include 
> the branch trace features commonly found in embedded processors?

Yes. P6-era and Opteron/Athlon 64 processors have LastBranchToIP /
LastBranchFromIP and LastExceptionToIP / LastExceptionFromIP MSRs that
can be enabled at runtime. Pentium 4 and Pentium M derived processors
can record the same data for the last four brances in to MSRs, and they
also have a much more complicated system where you can record all
branches to a buffer and get interrupts when that buffer would overflow,
etc.

Of course, Linux (and Linux debuggers) are still in the stone age and
don't support any of this. Somebody really needs to take ptrace() and
gdb out back and shoot them.

-- 
Nicholas Miell <nmiell at comcast.net>



From jspaleta at gmail.com  Thu Jul 28 01:26:01 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 27 Jul 2005 21:26:01 -0400
Subject: Rawhide updates & Fonts
In-Reply-To: <1122506931.3802.4.camel@localhost.localdomain>
References: <1122147771.4269.1.camel@scrappy.miketc.com>
	<1122149732.11316.0.camel@rousalka.dyndns.org>
	<1122485316.32580.11.camel@rousalka.dyndns.org>
	<1122495486.17926.78.camel@localhost.localdomain>
	<1122496739.1971.9.camel@rousalka.dyndns.org>
	<1122506931.3802.4.camel@localhost.localdomain>
Message-ID: <604aa791050727182632ea5eb3@mail.gmail.com>

On 7/27/05, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> No real chance of doing it this time (unless people are willing to
> reinstall or downgrade (would that even work?)) but might be worth
> noting for next time (as I'm sure there will be a next time).

For the future.... having a tool that testers can turn on to take
daily screenshots at a specified time potentially with a specially
designed text-rendering dialog window on screen might be useful to
avoid the "i wish we could downgrade" scenario. The tool would keep
the dated screenshots in a directory on disk and when a user notices a
problem.. they can simply flip back through the screenshots and figure
out when the rendering changed and show you the comparison and if you
are really lucky they can show you the segment of the yum.log that
pinpoints which packages were updated in that timeframe.

-jef



From mitr at volny.cz  Thu Jul 28 02:28:52 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 28 Jul 2005 04:28:52 +0200
Subject: Please test: mlocate
Message-ID: <20050728022847.GA3221@chrys.ms.mff.cuni.cz>

Hello,
http://people.redhat.com/mitr/mlocate/i386/mlocate-0.10-0.testing.1.i386.rpm
contains mlocate, a new locate implementation.  The 'm' stands for "merging":
updatedb reuses the existing database to avoid rereading most of the file
system, which makes updatedb faster and does not trash the system caches as
much (some data are at end of this message).

The locate(1) utility is intended to be completely compatible to slocate.
It also attempts to be compatible to GNU locate, when it does not conflict
with slocate compatibility.


mlocate seems to work well so far, but it has been tested only on ext3.
Because mlocate is sensitive to filesystem timestamp semantics,
testing with rarely used filesystems or uncommon automounting setups
would be most valuable.  Any other testing and comments are of course
welcome as well.

The package is prepared to install alongside slocate (it actually requires
slocate because I didn't want to allocate a GID for mlocate yet):
configure it at /etc/mupdatedb.conf and then just use (mlocate) instead
of (locate).

This is the first public release, so be please be careful: mlocate
certainly has a few bugs and it has not been independently audited 
for security issues.


Now, the promised numbers: each time, a computer was booted into
single-user mode; after one updatedb run data was collected using
(slabtop) and (free).  The measurement method is admittedly crude,
but I think the numbers represent reality quite well.

Run:		real	user	system	dentry	inode	buffers	cached
slocate:	1m32.84	0.704	2.045	134337	170778	85972	 8268
mlocate, 1st:	1m11.65	0.214	0.908	 17766	 15642	78452	21340
mlocate, 2nd:	  37.64	0.105	0.289	 17776   15639  33996   21336

real, user, system: as reported by (time)
dentry, inode: number of active objects in dentry_cache and ext3_inode_cache,
	as reported by (slabtop)
buffers, cached: size of disk buffers and page cache, as reported by (free).

mlocate has two rows because the first run needs to rescan the whole
file system, while the subsequent runs can reuse most of the original
database.
	Mirek



From rodd at clarkson.id.au  Thu Jul 28 04:56:07 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Thu, 28 Jul 2005 14:56:07 +1000
Subject: No GRUB loading on a 2 HD system
In-Reply-To: <42B813B0005C43CA@pne-smtpout1-sn1.fre.skanova.net> (added by
	postmaster@pne.skanova.net)
References: <42B813B0005C43CA@pne-smtpout1-sn1.fre.skanova.net>
	(added by postmaster@pne.skanova.net)
Message-ID: <1122526567.6542.2.camel@localhost.localdomain>

On Wed, 2005-07-27 at 23:16 +0200, DANEYE wrote:
> Hi:
> 
> On my computer I have 2 HDs ?n 160Gb each.
> 
> On the primary (no partitions)  I have WXPPro installed and on
> 
> the slave (no partitions)  I have recently installed Fedora Core 4.
> 
> My problem is that the GRUB doesn?t ?act? so there is no
> 
> booting choice: I always end up with the XP.
> 
> There are no ?what I can see- tips and tricks to find about my problem
> 
> in the Hudson/Hudson/Ball/Duff Red Hat Fedora 4 UNLEASHED.
> 
> Anybody who has hints in the matter?

Not the hint you were after I'm sure, but this list is for discussion of
rawhide development issues.

Since your really after help with a stable release of fedora, you're
better off asking your questions of fedora-users list, which is designed
to address your needs.


R.
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From Axel.Thimm at ATrpms.net  Thu Jul 28 08:22:57 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 28 Jul 2005 10:22:57 +0200
Subject: Please test: mlocate
In-Reply-To: <20050728022847.GA3221@chrys.ms.mff.cuni.cz>
References: <20050728022847.GA3221@chrys.ms.mff.cuni.cz>
Message-ID: <20050728082257.GA9759@neu.nirvana>

On Thu, Jul 28, 2005 at 04:28:52AM +0200, Miloslav Trmac wrote:
> The package is prepared to install alongside slocate (it actually requires
> slocate because I didn't want to allocate a GID for mlocate yet):
> configure it at /etc/mupdatedb.conf and then just use (mlocate) instead
> of (locate).

Couldn't mlocate just reuse (or use in parallel) the same gid? Both
entities should have the same security implications, so separating the
user/group ownership wouldn't help much.

BTW another feature often asked for in *locate is the ability to merge
different databases (usually from different nfs filesystems from
different hosts) into a super locatedb. Would that extension be easy
in mlocate (which already has merging code inside)?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050728/fb5949a1/attachment.sig>

From mitr at volny.cz  Thu Jul 28 09:21:07 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 28 Jul 2005 11:21:07 +0200
Subject: Please test: mlocate
In-Reply-To: <20050728082257.GA9759@neu.nirvana>
References: <20050728022847.GA3221@chrys.ms.mff.cuni.cz>
	<20050728082257.GA9759@neu.nirvana>
Message-ID: <20050728092102.GA3863@chrys.ms.mff.cuni.cz>

On Thu, Jul 28, 2005 at 10:22:57AM +0200, Axel Thimm wrote:
> On Thu, Jul 28, 2005 at 04:28:52AM +0200, Miloslav Trmac wrote:
> > The package is prepared to install alongside slocate (it actually requires
> > slocate because I didn't want to allocate a GID for mlocate yet):
> > configure it at /etc/mupdatedb.conf and then just use (mlocate) instead
> > of (locate).
> 
> Couldn't mlocate just reuse (or use in parallel) the same gid? Both
> entities should have the same security implications, so separating the
> user/group ownership wouldn't help much.
There is some theoretical risk: assuming one of the utilities can be
exploited by a carefully crafted database, it might be possible to
construct such a database by using the other updatedb against
a prepared filesystem.  Pretty far-fetched, I know.

> BTW another feature often asked for in *locate is the ability to merge
> different databases (usually from different nfs filesystems from
> different hosts) into a super locatedb. Would that extension be easy
> in mlocate (which already has merging code inside)?
A workaround is to set LOCATE_PATH to contain all the databases.
Writing a FreeBSD/OpenBSD-like concatdb should not be too difficult.
	Mirek



From fedora at camperquake.de  Thu Jul 28 10:48:20 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 12:48:20 +0200
Subject: Yesterday's rawhide sunk my iBook
Message-ID: <20050728104820.GA731@ryoko.camperquake.de>

Hi.

After applying yesterday's rawhide to my iBook, the system is quite
thoroughly toasted. After yum was finished, ssh'ing into the
machine no longer worke, and neither did logging in at the local
console. Rebooting the machine hangs after the initrd is processed,
seemingly failing to execute /sbin/init.

My suspicion is that a very low level library is botched (glibc or
selinux). Trying to chroot() into the system from an old YDL 3.0
install CD (the only CD what would boot on PPC I found on short
notice) fails, just producing segfaults, but YDL 3.0 is quite
old, of course, and still running 2.4. Will try and get a
FC4 install CD today and try again.

PS: The system does not use selinux.



From paul at all-the-johnsons.co.uk  Thu Jul 28 10:58:15 2005
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Thu, 28 Jul 2005 11:58:15 +0100
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728104820.GA731@ryoko.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
Message-ID: <1122548295.3004.29.camel@localhost>

Hi,

> After applying yesterday's rawhide to my iBook, the system is quite
> thoroughly toasted.

I think Jeff said it best - "Rawhide eats babies"

Sorry to hear about the problems though.

TTFN

Paul

-- 
"Some people will do anything for a woman in uniform" - The Doctor -
Unregenerate (Big Finish audio)



From fedora at camperquake.de  Thu Jul 28 11:11:38 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 13:11:38 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122548295.3004.29.camel@localhost>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122548295.3004.29.camel@localhost>
Message-ID: <20050728111138.GB731@ryoko.camperquake.de>

On Thu, Jul 28, 2005 at 11:58:15AM +0100, Paul F. Johnson wrote:
> > After applying yesterday's rawhide to my iBook, the system is quite
> > thoroughly toasted.
> 
> I think Jeff said it best - "Rawhide eats babies"

I know, and I am not complaining. That was just a head up warning
for other people that the danger level is slightly higher than
normal :)



From buildsys at redhat.com  Thu Jul 28 11:19:40 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 28 Jul 2005 07:19:40 -0400
Subject: rawhide report: 20050728 changes
Message-ID: <200507281119.j6SBJeHm032488@porkchop.devel.redhat.com>

New package scim
	Smart Common Input Method platform


 
Updated Packages:

dhcdbd-1.7-1
------------
* Wed Jul 27 2005 Jason Vas Dias <jvdias at redhat.com> 1.7-1
- fix bug 163711 / 162857: dhcdbd.init startup order
- improve security with system.d/dhcdbd.conf: allow only
  root user to send to dhcdbd

gdb-6.3.0.0-1.61
----------------
* Wed Jul 27 2005 Jeff Johnston <jjohnstn at redhat.com>   6.3.0.0-1.61
- Bump up release number.

gnome-doc-utils-0.3.2-1
-----------------------
* Wed Jul 27 2005 Christopher Aillon <caillon at redhat.com> - 0.3.2-1
- Update to 0.3.2

gphoto2-2.1.6-2
---------------
* Wed Jul 27 2005 Tim Waugh <twaugh at redhat.com> 2.1.6-2
- Rebuilt.

gtkhtml3-3.7.5-4
----------------
* Tue Jul 26 2005 David Malcolm <dmalcolm at redhat.com> - 3.7.5-4
- actually add patch to CVS this time

* Tue Jul 26 2005 David Malcolm <dmalcolm at redhat.com> - 3.7.5-3
- Added patch to use pango for cursor navigation and deletion, fixing problems
  with indic scripts (#129212)

isdn4k-utils-3.2-32
-------------------
* Wed Jul 27 2005 Than Ngo <than at redhat.com> 3.2-32 
- rebuilt

libsepol-1.7.6-2
----------------
* Wed Jul 27 2005 Dan Walsh <dwalsh at redhat.com> 1.7.6-2
- Fix MLS Free

* Mon Jul 25 2005 Dan Walsh <dwalsh at redhat.com> 1.7.6-1
- Upgrade to latest from NSA
	* Merged context reorganization, memory leak fixes, 
	  port and interface loading, replacements for genusers and
	  genbools, debug traceback, and bugfix patches from Ivan Gyurdiev.
	* Merged uninitialized variable bugfix from Dan Walsh.

mgetty-1.1.33-3_FC5
-------------------
* Fri Jul 22 2005 Jason Vas Dias <jvdias at redhat.com> 1.1.31-10
- fix bug 162174: prevent uninterruptable hang on exit() when
                  direct line disconnected (kernel bug 164002)
		  do tcflush(1,TCOFLUSH) before exit() in sig_goodbye()
	  	  block signals before entering syslog()
  workaround build system 'buffer overflow checks' bug:
                  use memcpy instead of sprintf in record.c, line 53

openoffice.org-1:1.9.121-3.2.0.fc5
----------------------------------
* Wed Jul 27 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.121-3
- add rh#164310# pipe giveup
- add openoffice.org-1.9.121.ooo52542.emptyrtfframes.sw.patch for rh#161313#

* Tue Jul 26 2005 Caolan McNamara <caolanm at redhat.com> - 1:1.9.121-2
- rh#127576# add libgnomeprintui 
- make database front end into pseudo subpackage
- replace patches with combined workspace.gslpatches4
- add rh#156677# menu changes

openssh-4.1p1-4
---------------
* Wed Jul 27 2005 Tomas Mraz <tmraz at redhat.com> 4.1p1-4
- don't deadlock on exit with multiple X forwarded channels (#152432)
- don't use X11 port which can't be bound on all IP families (#163732)

policycoreutils-1.25.3-1
------------------------
* Wed Jul 27 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-1
- Update to match NSA
	* Merged restorecon patch from Ivan Gyurdiev.

* Mon Jul 18 2005 Dan Walsh <dwalsh at redhat.com> 1.25.2-1
- Update to match NSA
	* Merged load_policy, newrole, and genhomedircon patches from Red Hat.

* Thu Jul 07 2005 Dan Walsh <dwalsh at redhat.com> 1.25.1-1
- Update to match NSA
	* Merged loadable module support from Tresys Technology.

rpm-4.4.2-3
-----------
* Wed Jul 27 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.2-2
- popt minor version requires

* Tue Jul 26 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.2-2
- popt minor version bump
- revert to perl.req/perl.prov for now

* Thu Jul 21 2005 Paul Nasrat <pnasrat at redhat.com> - 4.4.2-1
- Upgrade to upstream release

selinux-policy-strict-1.25.3-7
------------------------------
* Wed Jul 27 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-7
- Add certwatch.te
- Allow smbd to connect to smbd_port_t
- Fix hugetlb and mqueue

* Mon Jul 25 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-6
- Bump for FC4

selinux-policy-targeted-1.25.3-7
--------------------------------
* Wed Jul 27 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-7
- Add certwatch.te
- Allow smbd to connect to smbd_port_t
- Fix hugetlb and mqueue

* Mon Jul 25 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-6
- Bump for FC4

slrn-0.9.8.1-5
--------------
* Wed Jul 27 2005 Jindrich Novy <jnovy at redhat.com> 0.9.8.1-5
- apply official bugfix patches (#164363)
  - fixes slrnpull problem with group containing no headers
  - fixes last character removal editor problem

system-config-printer-0.6.138-1
-------------------------------
* Wed Jul 27 2005 Tim Waugh <twaugh at redhat.com> 0.6.138-1
- 0.6.138:
  - Fixed typo introduced in PTAL support.
  - Use hp-info from HPLIP package instead of our bundled utility.
  - Default to re-rendering PostScript when in a Russian locale (bug #160631).

tar-1.15.1-8
------------
* Wed Jul 27 2005 Peter Vrabec <pvrabec at redhat.com> 1.15.1-8
- A file is dumpable if it is sparse and both --sparse
  and --totals are specified (#154882)

Broken deps for i386
----------------------------------------------------------
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.i386 requires libpcap.so.0.9.1
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.i386 requires libpcap.so.0.9.1
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	mod_ssl - 1:2.0.54-11.i386 requires httpd = 1:2.0.54-11



Broken deps for ppc
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	ethereal - 0.10.11-4.ppc requires libpcap.so.0.9.1
	evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	mod_ssl - 1:2.0.54-11.ppc requires httpd = 1:2.0.54-11
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.ppc requires libpcap.so.0.9.1
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.ppc requires libpcap.so.0.9.1



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	ppp - 2.4.3-2.1.x86_64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	mod_ssl - 1:2.0.54-11.x86_64 requires httpd = 1:2.0.54-11



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	ethereal-gnome - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	mod_ssl - 1:2.0.54-11.ppc64 requires httpd = 1:2.0.54-11
	ppp - 2.4.3-2.1.ppc64 requires libpcap.so.0.9.1()(64bit)
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	ethereal - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	firstboot - 1.3.43-1.noarch requires system-config-display
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)



Broken deps for s390
----------------------------------------------------------
	selinux-policy-targeted - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	mod_ssl - 1:2.0.54-11.s390 requires httpd = 1:2.0.54-11
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	selinux-policy-strict-sources - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	selinux-policy-targeted-sources - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	ethereal - 0.10.11-4.s390 requires libpcap.so.0.9.1
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	ethereal-gnome - 0.10.11-4.s390 requires libpcap.so.0.9.1
	ppp - 2.4.3-2.1.s390 requires libpcap.so.0.9.1
	selinux-policy-strict - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10



Broken deps for ia64
----------------------------------------------------------
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3
	rgmanager - 1.9.31-3.ia64 requires ccs
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	mod_ssl - 1:2.0.54-11.ia64 requires httpd = 1:2.0.54-11
	ethereal - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit)
	ethereal-gnome - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	ppp - 2.4.3-2.1.ia64 requires libpcap.so.0.9.1()(64bit)



Broken deps for s390x
----------------------------------------------------------
	ppp - 2.4.3-2.1.s390x requires libpcap.so.0.9.1()(64bit)
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	selinux-policy-targeted - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	mod_ssl - 1:2.0.54-11.s390x requires httpd = 1:2.0.54-11
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	selinux-policy-strict - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	selinux-policy-targeted-sources - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit)
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	ethereal - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14
	selinux-policy-strict-sources - 1.25.3-7.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	ethereal-gnome - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	jonas - 4.3.3-1jpp_6fc.noarch requires carol = 0:1.8.9.3





From alan at redhat.com  Thu Jul 28 11:35:59 2005
From: alan at redhat.com (Alan Cox)
Date: Thu, 28 Jul 2005 07:35:59 -0400
Subject: GUI Debugger
In-Reply-To: <1122510763.2833.4.camel@localhost.localdomain>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
	<49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
	<1122462131.12276.3.camel@tarjei.predichem.nett>
	<18D1D305AFBE8BDCB1210D27@[192.168.5.135]>
	<1122510763.2833.4.camel@localhost.localdomain>
Message-ID: <20050728113559.GA16237@devserv.devel.redhat.com>

On Wed, Jul 27, 2005 at 05:32:43PM -0700, Nicholas Miell wrote:
> Of course, Linux (and Linux debuggers) are still in the stone age and
> don't support any of this. Somebody really needs to take ptrace() and
> gdb out back and shoot them.

There's nothing fundamentally stopping this in either the design of ptrace or
the architecture of gdb. Someone just needs to expose the relevant functions.
You can also BTW to TLB miss tracing on an x86 CPU with a few slightly evil
hacks.



From jfrieben at freesurf.fr  Thu Jul 28 11:50:46 2005
From: jfrieben at freesurf.fr (jfrieben at freesurf.fr)
Date: Thu, 28 Jul 2005 13:50:46 +0200 (CEST)
Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together
Message-ID: <44676.194.94.224.254.1122551446.squirrel@arlette.freesurf.fr>

I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
"savage" DRI support. After starting the graphical environment, X reports
"(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
In the beginning, "SELinux" used to be enabled by default. However, this
lead to segmentation faults when calling applications which depend on
OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg" entry read:

"Unable to handle kernel paging request at virtual address e0c10000
printing eip:
e0a2e458 *pde = 1d11c067
Oops: 0002 [#1]
Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd soundcore snd_page_alloc e100
mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
CPU:    0
EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
EFLAGS: 00010282   (2.6.12-1.1398_FC4)
EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
ds: 007b   es: 007b   ss: 0068
Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
       e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
d0614aa0
       ce556fc0Call Trace:
 [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
 [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
 [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
 [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
 [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
 [<c01931b1>] do_ioctl+0x51/0x55
 [<c01932a7>] vfs_ioctl+0x50/0x1aa
 [<c019345e>] sys_ioctl+0x5d/0x6b
 [<c0103a51>] syscall_call+0x7/0xb
Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"

There is a prior entry saying:

"mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"

The curious thing is that when "SELinux" is disabled at boot time through
option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
performance is pretty poor, but anyway. Has anybody observed this behaviour,
too? Any clues how to make SELinux and DRI make play together peacefully?




From jspaleta at gmail.com  Thu Jul 28 12:03:10 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 28 Jul 2005 08:03:10 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728104820.GA731@ryoko.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
Message-ID: <604aa79105072805032a705cde@mail.gmail.com>

On 7/28/05, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
> 
> After applying yesterday's rawhide to my iBook, the system is quite
> thoroughly toasted. After yum was finished, ssh'ing into the
> machine no longer worke, and neither did logging in at the local
> console. Rebooting the machine hangs after the initrd is processed,
> seemingly failing to execute /sbin/init.


You don't have a list of the packages you updated yesterday do you? 
Looking over yesterdays updates 20050727 I'm not seeing any thing from
yesterday that I would suspect that could have caused this.  yum
couldn't update the rpm package because of a broken dep.. and
everything seems to be particularly minor in terms of system
operation.

-jef



From fedora at camperquake.de  Thu Jul 28 12:31:00 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 14:31:00 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa79105072805032a705cde@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<604aa79105072805032a705cde@mail.gmail.com>
Message-ID: <20050728123100.GC731@ryoko.camperquake.de>

On Thu, Jul 28, 2005 at 08:03:10AM -0400, Jeff Spaleta wrote:

> You don't have a list of the packages you updated yesterday do you? 

IIRC yum writes such a list to /var/log after each update, so
it ought to be there, yes.

> Looking over yesterdays updates 20050727 I'm not seeing any thing from
> yesterday that I would suspect that could have caused this.

The system was not on a "the day before yesterday" state before
upgrading, so the cause could be further back in time. As said,
I suspect glibc or selinux, both of which were updated.
Sorry for the confusion.



From jspaleta at gmail.com  Thu Jul 28 13:00:36 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 28 Jul 2005 09:00:36 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728123100.GC731@ryoko.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<604aa79105072805032a705cde@mail.gmail.com>
	<20050728123100.GC731@ryoko.camperquake.de>
Message-ID: <604aa791050728060047e00c3e@mail.gmail.com>

On 7/28/05, Ralf Ertzinger <fedora at camperquake.de> wrote:
> On Thu, Jul 28, 2005 at 08:03:10AM -0400, Jeff Spaleta wrote:
> The system was not on a "the day before yesterday" state before
> upgrading, so the cause could be further back in time. As said,
> I suspect glibc or selinux, both of which were updated.
> Sorry for the confusion.


If you can get access to that yum.log we'll have a better idea. 
Unless you are the only ppc user tracking rawhide at all.. i would
have expected someone out there to be tracking rawhide daily on ppc
and would have expected them to scream about it before today if this
was caused by an 'older' update.  The fact that you are the first
person to scream about it.. doesn't bode well for re-producibility. 
Have you dived into the zilla yet to see if a ppc meltdown has been
reported in the last week?

-jef



From dwalsh at redhat.com  Thu Jul 28 15:12:49 2005
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Thu, 28 Jul 2005 11:12:49 -0400
Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together
In-Reply-To: <44676.194.94.224.254.1122551446.squirrel@arlette.freesurf.fr>
References: <44676.194.94.224.254.1122551446.squirrel@arlette.freesurf.fr>
Message-ID: <42E8F5F1.3020304@redhat.com>

jfrieben at freesurf.fr wrote:

>I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
>purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
>"savage" DRI support. After starting the graphical environment, X reports
>"(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
>In the beginning, "SELinux" used to be enabled by default. However, this
>lead to segmentation faults when calling applications which depend on
>OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg" entry read:
>
>"Unable to handle kernel paging request at virtual address e0c10000
>printing eip:
>e0a2e458 *pde = 1d11c067
>Oops: 0002 [#1]
>Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
>bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
>ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
>battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
>i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
>snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
>snd_timer snd soundcore snd_page_alloc e100
>mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
>CPU:    0
>EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
>EFLAGS: 00010282   (2.6.12-1.1398_FC4)
>EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
>eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
>esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
>ds: 007b   es: 007b   ss: 0068
>Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
>Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
>c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
>       e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
>d0614aa0
>       ce556fc0Call Trace:
> [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
> [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
> [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
> [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
> [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
> [<c01931b1>] do_ioctl+0x51/0x55
> [<c01932a7>] vfs_ioctl+0x50/0x1aa
> [<c019345e>] sys_ioctl+0x5d/0x6b
> [<c0103a51>] syscall_call+0x7/0xb
>Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
>d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
>81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"
>
>There is a prior entry saying:
>
>"mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"
>
>The curious thing is that when "SELinux" is disabled at boot time through
>option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
>performance is pretty poor, but anyway. Has anybody observed this behaviour,
>too? Any clues how to make SELinux and DRI make play together peacefully?
>
>
>  
>
Are you seeing any AVC messages in /var/log/messages or 
/var/log/audit/audit.log?

-- 




From bernie at develer.com  Thu Jul 28 16:08:07 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Thu, 28 Jul 2005 18:08:07 +0200
Subject: Firefox binary plugins on x86_64
In-Reply-To: <42E7098B.9060109@redhat.com>
References: <42E69966.6000606@develer.com> <42E7098B.9060109@redhat.com>
Message-ID: <42E902E7.3010402@develer.com>

Christopher Aillon wrote:
> Bernardo Innocenti wrote:
> 
>> Hello,
>>
>> somehow Firefox in SuSE 9.3 supports 32bit plugins on x86_64.
>> [...]
>>
> I just spoke to Wolfgang Rosenauer at SuSE (maintainer of their firefox
> package) who says you're mistaken.  SuSE ships both the 32 and 64 bit
> versions of the browser on x86-64 precisely for this problem, which I'm
> pretty sure we do as well.

Sorry for the confusion.  The SuSE machine where I've seen
this happening was upgraded from i586 to x86_64 by playing
dirty tricks with RPM packages, much like I've recently done
with my Fedora workstation.

In fact, that x86_64 SuSE system was actually still running
the i586 package of Firefox!  Sorry for all this confusion.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From dwmw2 at infradead.org  Thu Jul 28 16:13:35 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jul 2005 17:13:35 +0100
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728104820.GA731@ryoko.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
Message-ID: <1122567216.28128.78.camel@hades.cambridge.redhat.com>

On Thu, 2005-07-28 at 12:48 +0200, Ralf Ertzinger wrote:
> After applying yesterday's rawhide to my iBook, the system is quite
> thoroughly toasted. After yum was finished, ssh'ing into the
> machine no longer worke, and neither did logging in at the local
> console. Rebooting the machine hangs after the initrd is processed,
> seemingly failing to execute /sbin/init.

I just updated the Pegasos II box to rawhide, and it seems to be working
fine here. My first suspicion would be a failure to upgrade glibc
correctly.

-- 
dwmw2



From fedora at camperquake.de  Thu Jul 28 16:46:56 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 18:46:56 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122567216.28128.78.camel@hades.cambridge.redhat.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
Message-ID: <20050728184656.23324de5@nausicaa.camperquake.de>

Hi.

David Woodhouse <dwmw2 at infradead.org> wrote:

> I just updated the Pegasos II box to rawhide, and it seems to be working
> fine here. My first suspicion would be a failure to upgrade glibc
> correctly.

I have gotten the system up with a FC4-Install-CD, and there is some confusion
in the package db indeed. For example, I have currently 2 glibc packages
installed. Reinstalling the new packages from the rescue cd now.
Yay for rpm --root  (and the fact that yum does not immediately delete
package files after upgrade)

-- 
white mouse (n.) -- an animal which if killed in sufficient numbers
under controlled conditions produces a PhD.



From jspaleta at gmail.com  Thu Jul 28 17:11:05 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 28 Jul 2005 13:11:05 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728184656.23324de5@nausicaa.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
Message-ID: <604aa79105072810116a292ef3@mail.gmail.com>

On 7/28/05, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
> 
> David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > I just updated the Pegasos II box to rawhide, and it seems to be working
> > fine here. My first suspicion would be a failure to upgrade glibc
> > correctly.
> 
> I have gotten the system up with a FC4-Install-CD, and there is some confusion
> in the package db indeed. For example, I have currently 2 glibc packages
> installed. 

If you have 2 versions installed.. and the latest version was an
upgrade attempt via yum.. it sounds like there was a problem that
prevented the cleanup portion of the rpm transaction from completing
correctly. Was this an automated run of yum while you were afk.. or
did you happen to watch the output scroll? If there is a scriptlet
error or some other type of problem that rpm notices, there might be a
message to stdout or stderr. The error messages rpm throws don't show
up in the yum log however so you'd need the actually stdout and stderr
for the yum session you ran.

You might want to look for other duplicate packages which might have
also failed to cleanup correctly.

alias dupes='rpm -aq --queryformat "%{NAME}\n" | sort | uniq -c | grep
-v -E " *1 "'

-jef



From dwmw2 at infradead.org  Thu Jul 28 17:30:38 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jul 2005 18:30:38 +0100
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa79105072810116a292ef3@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
Message-ID: <1122571839.28128.80.camel@hades.cambridge.redhat.com>

On Thu, 2005-07-28 at 13:11 -0400, Jeff Spaleta wrote:
> If you have 2 versions installed.. and the latest version was an
> upgrade attempt via yum.. it sounds like there was a problem that
> prevented the cleanup portion of the rpm transaction from completing
> correctly.

I see this kind of thing quite often. It doesn't help that yum will
often leave quite a lot of time between installing the new version of a
given package and uninstalling the old one. 

-- 
dwmw2



From skvidal at phy.duke.edu  Thu Jul 28 17:37:40 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 28 Jul 2005 13:37:40 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122571839.28128.80.camel@hades.cambridge.redhat.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<1122571839.28128.80.camel@hades.cambridge.redhat.com>
Message-ID: <1122572261.19679.20.camel@cutter>

On Thu, 2005-07-28 at 18:30 +0100, David Woodhouse wrote:
> On Thu, 2005-07-28 at 13:11 -0400, Jeff Spaleta wrote:
> > If you have 2 versions installed.. and the latest version was an
> > upgrade attempt via yum.. it sounds like there was a problem that
> > prevented the cleanup portion of the rpm transaction from completing
> > correctly.
> 
> I see this kind of thing quite often. It doesn't help that yum will
> often leave quite a lot of time between installing the new version of a
> given package and uninstalling the old one. 
> 

yum does a ts.order() - it's using rpm's transaction ordering - how
would you like for yum to speed up that time?

-sv




From fedora at camperquake.de  Thu Jul 28 17:39:18 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 19:39:18 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa79105072810116a292ef3@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
Message-ID: <20050728193918.2a204a92@nausicaa.camperquake.de>

Hi.

Jeff Spaleta <jspaleta at gmail.com> wrote:

> If you have 2 versions installed.. and the latest version was an
> upgrade attempt via yum.. it sounds like there was a problem that
> prevented the cleanup portion of the rpm transaction from completing
> correctly. Was this an automated run of yum while you were afk.. or
> did you happen to watch the output scroll?

I semi-watched it. There were some failed scripts, but nothing glibc
related as far as I recall.

> You might want to look for other duplicate packages which might have
> also failed to cleanup correctly.

There were some of those, but the main cause was glibc. After
reinstalling that I could chroot() into the system again. The
rest will be reinstalled after rebooting.



From laroche at redhat.com  Thu Jul 28 17:41:23 2005
From: laroche at redhat.com (Florian La Roche)
Date: Thu, 28 Jul 2005 19:41:23 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122572261.19679.20.camel@cutter>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<1122571839.28128.80.camel@hades.cambridge.redhat.com>
	<1122572261.19679.20.camel@cutter>
Message-ID: <20050728174123.GA10679@dudweiler.stuttgart.redhat.com>

On Thu, Jul 28, 2005 at 01:37:40PM -0400, seth vidal wrote:
> On Thu, 2005-07-28 at 18:30 +0100, David Woodhouse wrote:
> > On Thu, 2005-07-28 at 13:11 -0400, Jeff Spaleta wrote:
> > > If you have 2 versions installed.. and the latest version was an
> > > upgrade attempt via yum.. it sounds like there was a problem that
> > > prevented the cleanup portion of the rpm transaction from completing
> > > correctly.
> > 
> > I see this kind of thing quite often. It doesn't help that yum will
> > often leave quite a lot of time between installing the new version of a
> > given package and uninstalling the old one. 
> > 
> 
> yum does a ts.order() - it's using rpm's transaction ordering - how
> would you like for yum to speed up that time?

What about the cleanup scripts or removing old files? Looks to me
like all that is only done at the very end right now. Maybe completing
individual package updates in one step before updating the next
package should be an option for users.

greetings,

Florian La Roche



From dimi at lattica.com  Thu Jul 28 17:39:41 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 28 Jul 2005 13:39:41 -0400
Subject: Yesterday's rawhide sunk my iBook
References: <20050728104820.GA731@ryoko.camperquake.de><1122567216.28128.78.camel@hades.cambridge.redhat.com><20050728184656.23324de5@nausicaa.camperquake.de><604aa79105072810116a292ef3@mail.gmail.com><1122571839.28128.80.camel@hades.cambridge.redhat.com>
	<1122572261.19679.20.camel@cutter>
Message-ID: <01fd01c5939b$55eda9e0$b6491b31@td612671>

From: "seth vidal" <skvidal at phy.duke.edu>
> yum does a ts.order() - it's using rpm's transaction ordering - how
> would you like for yum to speed up that time?

Speaking of which, if things are left behind in case of a problem,
this is not very transactional, is it?

Obviously, this is not yum's fault, but rather RPM's -- shouldn't
RPM transactions be a bit more ACID?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From skvidal at phy.duke.edu  Thu Jul 28 17:44:30 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 28 Jul 2005 13:44:30 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <01fd01c5939b$55eda9e0$b6491b31@td612671>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<1122571839.28128.80.camel@hades.cambridge.redhat.com>
	<1122572261.19679.20.camel@cutter>
	<01fd01c5939b$55eda9e0$b6491b31@td612671>
Message-ID: <1122572670.19679.22.camel@cutter>

On Thu, 2005-07-28 at 13:39 -0400, Dimi Paun wrote:
> From: "seth vidal" <skvidal at phy.duke.edu>
> > yum does a ts.order() - it's using rpm's transaction ordering - how
> > would you like for yum to speed up that time?
> 
> Speaking of which, if things are left behind in case of a problem,
> this is not very transactional, is it?
> 
> Obviously, this is not yum's fault, but rather RPM's -- shouldn't
> RPM transactions be a bit more ACID?

a lot easier said than done.

it's not just a db transaction - it's also a fs and script transaction.
Often time lots of the %scriptlets can't be reversed.

-sv




From jspaleta at gmail.com  Thu Jul 28 17:42:52 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 28 Jul 2005 13:42:52 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122571839.28128.80.camel@hades.cambridge.redhat.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<1122571839.28128.80.camel@hades.cambridge.redhat.com>
Message-ID: <604aa7910507281042690ec93f@mail.gmail.com>

On 7/28/05, David Woodhouse <dwmw2 at infradead.org> wrote:
> I see this kind of thing quite often. It doesn't help that yum will
> often leave quite a lot of time between installing the new version of a
> given package and uninstalling the old one.

A lot of time... would mean you are doing a lot of updates.  You'd
rather yum do  install/clean up  one package at a time?  I think that
leads to a whole other nest of problems. I don't even think cli rpm
does updates that way when you give it a big list of packages to
update.

I'm personally more concerned about rpm learning how to pass messages
back through its python bindings so yum and other tools can actually
log rpm level messages.. instead of having to screenscrape to know
what rpm was spitting out to stdout and stderr. I'm pretty sure
scriptlet failures have to be screenscraped as well as messages of
rpmnew and rpmsave files.

-jef



From jspaleta at gmail.com  Thu Jul 28 17:48:42 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 28 Jul 2005 13:48:42 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728193918.2a204a92@nausicaa.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<20050728193918.2a204a92@nausicaa.camperquake.de>
Message-ID: <604aa7910507281048764a3b50@mail.gmail.com>

On 7/28/05, Ralf Ertzinger <fedora at camperquake.de> wrote:
> There were some of those, but the main cause was glibc.

And my point is... if glibc failed to cleanup or install correctly...
then there could very well have been a scriptlet error for glibc. The
postinstall scriptlet for glibc is rather.... unique.. as far as
scriptlets go.  People with ppc hardware need to try to reproduce
this. If there is a pedantic situational bug in
/usr/sbin/glibc_post_upgrade.*  its in your best interest to look at
this more closely.

-jef



From pnasrat at redhat.com  Thu Jul 28 18:08:09 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Thu, 28 Jul 2005 14:08:09 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa7910507281048764a3b50@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<20050728193918.2a204a92@nausicaa.camperquake.de>
	<604aa7910507281048764a3b50@mail.gmail.com>
Message-ID: <1122574089.3921.4.camel@enki.eridu>

On Thu, 2005-07-28 at 13:48 -0400, Jeff Spaleta wrote:
> On 7/28/05, Ralf Ertzinger <fedora at camperquake.de> wrote:
> > There were some of those, but the main cause was glibc.
> 
> And my point is... if glibc failed to cleanup or install correctly...
> then there could very well have been a scriptlet error for glibc. The
> postinstall scriptlet for glibc is rather.... unique.. as far as
> scriptlets go.  People with ppc hardware need to try to reproduce
> this. If there is a pedantic situational bug in
> /usr/sbin/glibc_post_upgrade.*  its in your best interest to look at
> this more closely.

Or a trigger failure - redhat-lsb has caused this in the past

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160585

Without reproducibility and logs it's impossible to say.

Paul



From fedora at camperquake.de  Thu Jul 28 18:06:02 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 20:06:02 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa7910507281048764a3b50@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<20050728193918.2a204a92@nausicaa.camperquake.de>
	<604aa7910507281048764a3b50@mail.gmail.com>
Message-ID: <20050728200602.3dbc592d@nausicaa.camperquake.de>

Hi.

Jeff Spaleta <jspaleta at gmail.com> wrote:

> And my point is... if glibc failed to cleanup or install correctly...
> then there could very well have been a scriptlet error for glibc. The
> postinstall scriptlet for glibc is rather.... unique.. as far as
> scriptlets go.  People with ppc hardware need to try to reproduce
> this. If there is a pedantic situational bug in
> /usr/sbin/glibc_post_upgrade.*  its in your best interest to look at
> this more closely.

I think yum rums %postinstall in the first phase of the upgrade
(Upgrading <....>). The glibc script restarts the sshd, and this
is noticeable in the console output. I remeber seeing this yesterday,
and there were no visible errors on the console at this stage.

We'll see if the next upgrade goes well.

-- 
Disloyalty: There comes a time when every team must learn to make
individual sacrifices.            -- Despair Inc. calendar, September 2001



From fedora at camperquake.de  Thu Jul 28 18:17:09 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 28 Jul 2005 20:17:09 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122574089.3921.4.camel@enki.eridu>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<20050728193918.2a204a92@nausicaa.camperquake.de>
	<604aa7910507281048764a3b50@mail.gmail.com>
	<1122574089.3921.4.camel@enki.eridu>
Message-ID: <20050728201709.683c47b2@nausicaa.camperquake.de>

Hi.

Paul Nasrat <pnasrat at redhat.com> wrote:

> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160585
> 
> Without reproducibility and logs it's impossible to say.

All I can offer you is the list of files that yum upgraded.
Maybe yum ought to log script errors, too.

-- 
Q. How many people does it take to change a lightbulb on Usenet?
A. 1 to say the light's out, 100 to say "Yes, I noticed that", and 1,000 
   to post requests for FTP sites with free software that replaces
   lightbulbs. Meanwhile, it's still dark.



From jspaleta at gmail.com  Thu Jul 28 18:18:53 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 28 Jul 2005 14:18:53 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122574089.3921.4.camel@enki.eridu>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<20050728193918.2a204a92@nausicaa.camperquake.de>
	<604aa7910507281048764a3b50@mail.gmail.com>
	<1122574089.3921.4.camel@enki.eridu>
Message-ID: <604aa791050728111853d324e8@mail.gmail.com>

On 7/28/05, Paul Nasrat <pnasrat at redhat.com> wrote:
> Or a trigger failure - redhat-lsb has caused this in the past
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160585
> 
> Without reproducibility and logs it's impossible to say.

blasted triggers..... does the ppc redhat-lsb package have something
ppc specific?

-jef



From pnasrat at redhat.com  Thu Jul 28 18:25:21 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Thu, 28 Jul 2005 14:25:21 -0400
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa791050728111853d324e8@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<20050728193918.2a204a92@nausicaa.camperquake.de>
	<604aa7910507281048764a3b50@mail.gmail.com>
	<1122574089.3921.4.camel@enki.eridu>
	<604aa791050728111853d324e8@mail.gmail.com>
Message-ID: <1122575122.3921.8.camel@enki.eridu>

On Thu, 2005-07-28 at 14:18 -0400, Jeff Spaleta wrote:
> On 7/28/05, Paul Nasrat <pnasrat at redhat.com> wrote:
> > Or a trigger failure - redhat-lsb has caused this in the past
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160585
> > 
> > Without reproducibility and logs it's impossible to say.
> 
> blasted triggers..... does the ppc redhat-lsb package have something
> ppc specific?

No it has a trigger on glibc

Paul



From jerone at gmail.com  Thu Jul 28 20:11:41 2005
From: jerone at gmail.com (Jerone Young)
Date: Thu, 28 Jul 2005 15:11:41 -0500
Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together
In-Reply-To: <44676.194.94.224.254.1122551446.squirrel@arlette.freesurf.fr>
References: <44676.194.94.224.254.1122551446.squirrel@arlette.freesurf.fr>
Message-ID: <9f50a7a00507281311662d1fc5@mail.gmail.com>

I had your exact laptop about a few months ago. The DRI driver does
not support the mobile version of the Savage card. So your out of luck
when it comes to 3D support on your T23.

On 7/28/05, jfrieben at freesurf.fr <jfrieben at freesurf.fr> wrote:
> I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
> purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
> "savage" DRI support. After starting the graphical environment, X reports
> "(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
> In the beginning, "SELinux" used to be enabled by default. However, this
> lead to segmentation faults when calling applications which depend on
> OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg" entry read:
> 
> "Unable to handle kernel paging request at virtual address e0c10000
> printing eip:
> e0a2e458 *pde = 1d11c067
> Oops: 0002 [#1]
> Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
> bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
> ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
> battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
> i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
> snd_timer snd soundcore snd_page_alloc e100
> mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
> CPU:    0
> EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
> EFLAGS: 00010282   (2.6.12-1.1398_FC4)
> EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
> eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
> esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
> ds: 007b   es: 007b   ss: 0068
> Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
> Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
> c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
>        e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
> d0614aa0
>        ce556fc0Call Trace:
>  [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
>  [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
>  [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
>  [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
>  [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
>  [<c01931b1>] do_ioctl+0x51/0x55
>  [<c01932a7>] vfs_ioctl+0x50/0x1aa
>  [<c019345e>] sys_ioctl+0x5d/0x6b
>  [<c0103a51>] syscall_call+0x7/0xb
> Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
> d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
> 81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"
> 
> There is a prior entry saying:
> 
> "mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"
> 
> The curious thing is that when "SELinux" is disabled at boot time through
> option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
> performance is pretty poor, but anyway. Has anybody observed this behaviour,
> too? Any clues how to make SELinux and DRI make play together peacefully?
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jerone at gmail.com  Thu Jul 28 20:14:22 2005
From: jerone at gmail.com (Jerone Young)
Date: Thu, 28 Jul 2005 15:14:22 -0500
Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together
In-Reply-To: <9f50a7a00507281311662d1fc5@mail.gmail.com>
References: <44676.194.94.224.254.1122551446.squirrel@arlette.freesurf.fr>
	<9f50a7a00507281311662d1fc5@mail.gmail.com>
Message-ID: <9f50a7a005072813147eadf696@mail.gmail.com>

Forget what I said....you wow it now works .. coolness.

On 7/28/05, Jerone Young <jerone at gmail.com> wrote:
> I had your exact laptop about a few months ago. The DRI driver does
> not support the mobile version of the Savage card. So your out of luck
> when it comes to 3D support on your T23.
> 
> On 7/28/05, jfrieben at freesurf.fr <jfrieben at freesurf.fr> wrote:
> > I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
> > purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
> > "savage" DRI support. After starting the graphical environment, X reports
> > "(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
> > In the beginning, "SELinux" used to be enabled by default. However, this
> > lead to segmentation faults when calling applications which depend on
> > OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg" entry read:
> >
> > "Unable to handle kernel paging request at virtual address e0c10000
> > printing eip:
> > e0a2e458 *pde = 1d11c067
> > Oops: 0002 [#1]
> > Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
> > bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
> > ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
> > battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
> > i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
> > snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
> > snd_timer snd soundcore snd_page_alloc e100
> > mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
> > CPU:    0
> > EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
> > EFLAGS: 00010282   (2.6.12-1.1398_FC4)
> > EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
> > eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
> > esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
> > ds: 007b   es: 007b   ss: 0068
> > Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
> > Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
> > c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
> >        e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
> > d0614aa0
> >        ce556fc0Call Trace:
> >  [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
> >  [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
> >  [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
> >  [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
> >  [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
> >  [<c01931b1>] do_ioctl+0x51/0x55
> >  [<c01932a7>] vfs_ioctl+0x50/0x1aa
> >  [<c019345e>] sys_ioctl+0x5d/0x6b
> >  [<c0103a51>] syscall_call+0x7/0xb
> > Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
> > d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
> > 81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"
> >
> > There is a prior entry saying:
> >
> > "mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"
> >
> > The curious thing is that when "SELinux" is disabled at boot time through
> > option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
> > performance is pretty poor, but anyway. Has anybody observed this behaviour,
> > too? Any clues how to make SELinux and DRI make play together peacefully?
> >
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > http://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>



From jfrieben at freesurf.fr  Thu Jul 28 20:31:11 2005
From: jfrieben at freesurf.fr (jfrieben at freesurf.fr)
Date: Thu, 28 Jul 2005 22:31:11 +0200 (CEST)
Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together
In-Reply-To: <42E8F5F1.3020304@redhat.com>
References: <42E8F5F1.3020304@redhat.com>
Message-ID: <54498.194.94.224.254.1122582671.squirrel@jose.freesurf.fr>

There are many AVC entries in both files "/var/log/messages" and
"/var/log/audit/audit.log". However, they do not seem to be related to the
use of DRM. In particular, there is no additional entry upon call of
"glxinfo" related to the SELinux framework, whereas there is some output to
"/var/log/dmesg". If "SELinux" had intercepted some unauthorized
access/action, it should at least have reported this somewhat more verbosely
instead of simply crashing the X server in the case of "glxgears" - right?
Here comes the snippet from "/var/log/messages" with AVC related stuff from
the system boot procedure:

"Jul 28 19:38:04 riemann kernel: audit(1122572272.500:3): avc:  denied  {
read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: audit(1122572272.500:4): avc:  denied  {
read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: audit(1122572272.500:5): avc:  denied  {
read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: audit(1122572272.500:6): avc:  denied  {
read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: SELinux: initialized (dev rpc_pipefs, type
rpc_pipefs), uses genfs_contexts".




From jbarnes at virtuousgeek.org  Thu Jul 28 21:41:57 2005
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Thu, 28 Jul 2005 14:41:57 -0700
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728104820.GA731@ryoko.camperquake.de>
References: <20050728104820.GA731@ryoko.camperquake.de>
Message-ID: <200507281441.58121.jbarnes@virtuousgeek.org>

On Thursday, July 28, 2005 3:48 am, Ralf Ertzinger wrote:
> Hi.
>
> After applying yesterday's rawhide to my iBook, the system is quite
> thoroughly toasted. After yum was finished, ssh'ing into the
> machine no longer worke, and neither did logging in at the local
> console. Rebooting the machine hangs after the initrd is processed,
> seemingly failing to execute /sbin/init.
>
> My suspicion is that a very low level library is botched (glibc or
> selinux). Trying to chroot() into the system from an old YDL 3.0
> install CD (the only CD what would boot on PPC I found on short
> notice) fails, just producing segfaults, but YDL 3.0 is quite
> old, of course, and still running 2.4. Will try and get a
> FC4 install CD today and try again.
>
> PS: The system does not use selinux.

I noticed the same thing when I updated my PowerBook yesterday.  The 
machine wouldn't even reboot after the 'yum update' was complete; after 
'starting nash' I didn't see any output.  I had to boot from an old FC4 
CD and recover.

What I found was that glibc was apparently busted (everything 
segfaulted), along with ld.so, libk5crypto (fixing those fixed the 
'Illegal instructions' I was getting) and maybe one or two others.  I 
had to copy them from my boot image, install a new kernel and initrd, 
and reboot to downgrade to the older glibc.  I didn't see any errors 
during the upgrade either, so I'm not sure what went wrong (though the 
logs are probably still there).

Jesse



From ldave at droberts.com  Fri Jul 29 01:17:44 2005
From: ldave at droberts.com (Dave Roberts)
Date: Thu, 28 Jul 2005 18:17:44 -0700
Subject: [Fwd: randomize_va_space default change?]
Message-ID: <1122599864.4422.60.camel@linux.droberts.com>

I originally sent this to the Fedora users list earlier this morning but
didn't get a single response as of this evening. Upon reflection, it
seemed like a good idea to send this to the developers list.

If anybody can point me to a comprehensive explanation of all the
various exec-shield technologies and the ways they interact with
different kernel versions, gcc versions, etc., I would be happy to RTFM.
As of now, Googling had just returned various bits and pieces, many of
which already seem out of date as exec-shield has evolved and gotten
into upstream kernel work.

-- Dave

-------- Forwarded Message --------
From: Dave Roberts <ldave at droberts.com>
Reply-To: For users of Fedora Core releases <fedora-list at redhat.com>
To: For users of Fedora Core releases <fedora-list at redhat.com>
Subject: randomize_va_space default change?
Date: Thu, 28 Jul 2005 11:08:11 -0700
Did something just change with one of the latest kernel releases for FC3
to enable randomize_va_space by default? I had a program (sbcl - Steel
Bank Common Lisp) that was working fine with previous kernels and now
seems to be having trouble with address space randomization.

Either that, or was there a setting change in gcc that now defaults to
allowing randomization in some ELF header bit somewhere? Perhaps in gcc
3.4.3 or thereabouts? I have noticed that binaries built after sometime
in May suffer from the problem but older binaries don't. Further, newer
binaries didn't start suffering until running them with recent kernels
and/or glibcs.

I'm having a lot of trouble finding information about how
randomize_va_space works. Setting it to 0 in /proc/... works fine, but
I'd rather have some way to build sbcl such that I can mark it as
incompatible with address space randomization rather than turning off
this feature for the whole system. I know that other exec-shield
features have ELF bits that can be flipped with build options, but they
seem to default to being off for compatibility's sake.

-- 
Dave Roberts <ldave at droberts.com>

-- 
Dave Roberts <ldave at droberts.com>



From nmiell at comcast.net  Fri Jul 29 03:15:55 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Thu, 28 Jul 2005 20:15:55 -0700
Subject: GUI Debugger
In-Reply-To: <20050728113559.GA16237@devserv.devel.redhat.com>
References: <CE64B4655C60F4B88759DAB9@[10.0.0.14]>
	<1122377597.12276.1.camel@tarjei.predichem.nett>
	<49D342CEC4A6CFDCF29DF1B9@[10.169.6.233]>
	<1122462131.12276.3.camel@tarjei.predichem.nett>
	<18D1D305AFBE8BDCB1210D27@[192.168.5.135]>
	<1122510763.2833.4.camel@localhost.localdomain>
	<20050728113559.GA16237@devserv.devel.redhat.com>
Message-ID: <1122606955.2833.0.camel@localhost.localdomain>

On Thu, 2005-07-28 at 07:35 -0400, Alan Cox wrote:
> On Wed, Jul 27, 2005 at 05:32:43PM -0700, Nicholas Miell wrote:
> > Of course, Linux (and Linux debuggers) are still in the stone age and
> > don't support any of this. Somebody really needs to take ptrace() and
> > gdb out back and shoot them.
> 
> There's nothing fundamentally stopping this in either the design of ptrace or
> the architecture of gdb. Someone just needs to expose the relevant functions.
> You can also BTW to TLB miss tracing on an x86 CPU with a few slightly evil
> hacks.

Actually, at this point in time I'd just be happy if GDB would notice
when threads died. And stop segfaulting randomly.

-- 
Nicholas Miell <nmiell at comcast.net>



From tagoh at redhat.com  Fri Jul 29 07:45:48 2005
From: tagoh at redhat.com (Akira TAGOH)
Date: Fri, 29 Jul 2005 16:45:48 +0900 (JST)
Subject: PROPOSAL: porting emacsen-comon from Debian
Message-ID: <20050729.164548.-108808988.tagoh@redhat.com>


Hi,

I'd bring this issue up here. right now all elisp packages
has been bytecompilied at the build time. that worked fine
until now.  However xemacs has been moved to Extras and we
have had the possiblity of having the multiple version of
[x]emacs against the existance of Extras. consequently it
takes the problem rise. say, the elisp packages in Core
can't provides the bytecompiled elisp for xemacs, because
Core packages can't depends on Extras packages.  people
needs to have their own (duplicated) elisp packages to be
bytecompiled or needs any extra work for that. etc. and you
may wants to try the emacs CVS snapshot package. but it may
not work properly due to the incompatibility of the
bytecompiled code.

For such problems, Debian has the good thing to solve
them. emacsen-common package provides the facilities to
install the elisp files. although each elisp packages needs
to have a script to bytecompile them, it will be brought
up with every favor of [x]emacs from emacsen-common and the
elisp packages can provides the bytecompiled elisp without
installing each elisp packages like -el and -el-xemacs for
[x]emacs installed on your system.


The description may be insufficient. please comment on this,
if you have any objections. the discussion is always welcome :)


Thanks,
--
Akira TAGOH



From dwalsh at redhat.com  Fri Jul 29 10:13:27 2005
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 29 Jul 2005 06:13:27 -0400
Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together
In-Reply-To: <54498.194.94.224.254.1122582671.squirrel@jose.freesurf.fr>
References: <42E8F5F1.3020304@redhat.com>
	<54498.194.94.224.254.1122582671.squirrel@jose.freesurf.fr>
Message-ID: <42EA0147.4020601@redhat.com>

jfrieben at freesurf.fr wrote:

>There are many AVC entries in both files "/var/log/messages" and
>"/var/log/audit/audit.log". However, they do not seem to be related to the
>use of DRM. In particular, there is no additional entry upon call of
>"glxinfo" related to the SELinux framework, whereas there is some output to
>"/var/log/dmesg". If "SELinux" had intercepted some unauthorized
>access/action, it should at least have reported this somewhat more verbosely
>instead of simply crashing the X server in the case of "glxgears" - right?
>Here comes the snippet from "/var/log/messages" with AVC related stuff from
>the system boot procedure:
>
>"Jul 28 19:38:04 riemann kernel: audit(1122572272.500:3): avc:  denied  {
>read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
>scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
>tclass=file
>Jul 28 19:38:04 riemann kernel: audit(1122572272.500:4): avc:  denied  {
>read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
>scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
>tclass=file
>Jul 28 19:38:04 riemann kernel: audit(1122572272.500:5): avc:  denied  {
>read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
>scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
>tclass=file
>Jul 28 19:38:04 riemann kernel: audit(1122572272.500:6): avc:  denied  {
>read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
>scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
>tclass=file
>Jul 28 19:38:04 riemann kernel: SELinux: initialized (dev rpc_pipefs, type
>rpc_pipefs), uses genfs_contexts".
>
>
>  
>
This looks like you have some kind of labeleing problem.  utmp is labled 
init_var_run_t, it should be initrc_var_run_t
You may want to relabel.
Have you tried to boot with enforcing=0? 

Dan

-- 




From mls at suse.de  Fri Jul 29 10:52:38 2005
From: mls at suse.de (Michael Schroeder)
Date: Fri, 29 Jul 2005 12:52:38 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <604aa7910507281042690ec93f@mail.gmail.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<1122571839.28128.80.camel@hades.cambridge.redhat.com>
	<604aa7910507281042690ec93f@mail.gmail.com>
Message-ID: <20050729105238.GA3456@suse.de>

On Thu, Jul 28, 2005 at 01:42:52PM -0400, Jeff Spaleta wrote:
> A lot of time... would mean you are doing a lot of updates.  You'd
> rather yum do  install/clean up  one package at a time?  I think that
> leads to a whole other nest of problems. I don't even think cli rpm
> does updates that way when you give it a big list of packages to
> update.

Well, old rpm versions used to do the uninstall right after the install.
I don't know why it was changed, the new way has some big disadvantages,
for example you get lots of duplicate packages if rpm exits in the
middle of the update.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From mls at suse.de  Fri Jul 29 10:54:18 2005
From: mls at suse.de (Michael Schroeder)
Date: Fri, 29 Jul 2005 12:54:18 +0200
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <20050728174123.GA10679@dudweiler.stuttgart.redhat.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
	<20050728184656.23324de5@nausicaa.camperquake.de>
	<604aa79105072810116a292ef3@mail.gmail.com>
	<1122571839.28128.80.camel@hades.cambridge.redhat.com>
	<1122572261.19679.20.camel@cutter>
	<20050728174123.GA10679@dudweiler.stuttgart.redhat.com>
Message-ID: <20050729105418.GB3456@suse.de>

On Thu, Jul 28, 2005 at 07:41:23PM +0200, Florian La Roche wrote:
> What about the cleanup scripts or removing old files? Looks to me
> like all that is only done at the very end right now. Maybe completing
> individual package updates in one step before updating the next
> package should be an option for users.

Please talk to your rpm maintainer, this was an intentional change
in rpm-4.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From dwmw2 at infradead.org  Fri Jul 29 11:11:09 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 29 Jul 2005 12:11:09 +0100
Subject: Yesterday's rawhide sunk my iBook
In-Reply-To: <1122567216.28128.78.camel@hades.cambridge.redhat.com>
References: <20050728104820.GA731@ryoko.camperquake.de>
	<1122567216.28128.78.camel@hades.cambridge.redhat.com>
Message-ID: <1122635470.28128.85.camel@hades.cambridge.redhat.com>

On Thu, 2005-07-28 at 17:13 +0100, David Woodhouse wrote:
> On Thu, 2005-07-28 at 12:48 +0200, Ralf Ertzinger wrote:
> > After applying yesterday's rawhide to my iBook, the system is quite
> > thoroughly toasted. After yum was finished, ssh'ing into the
> > machine no longer worke, and neither did logging in at the local
> > console. Rebooting the machine hangs after the initrd is processed,
> > seemingly failing to execute /sbin/init.
> 
> I just updated the Pegasos II box to rawhide, and it seems to be
> working fine here. My first suspicion would be a failure to upgrade
> glibc correctly.

It was fine immediately after the upgrade but it died overnight, when
prelink happened. Un-prelinking /lib/ld-2.3.90.so makes it all work
again.

-- 
dwmw2



From buildsys at redhat.com  Fri Jul 29 11:21:52 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 29 Jul 2005 07:21:52 -0400
Subject: rawhide report: 20050729 changes
Message-ID: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>

New package anthy
	Japanese character set input library

New package libsemanage
	SELinux binary policy manipulation library


 
Updated Packages:

binutils-2.16.91.0.2-2
----------------------
* Fri Jul 29 2005 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.2-2
- don't complain about relocs to discarded sections in ppc32
  .got2 sections (Alan Modra, PR target/17828)

cairo-0.6.0-1
-------------
* Thu Jul 28 2005 Owen Taylor <otaylor at devserv.devel.redhat.com> 0.6.0-1
- Update to cairo-0.6.0

distcache-1.4.5-10
------------------
* Thu Jul 28 2005 Joe Orton <jorton at redhat.com> 1.4.5-10
- fix broken deps

eclipse-1:3.1.0_fc-12
---------------------
* Thu Jul 28 2005 Gary Benson <gbenson at redhat.com> 3.1.0_fc-12
- Allow leading separators in classpaths (e.o#105430).
- Clear away ant-jmf entirely.

* Wed Jul 27 2005 Andrew Overholt <overholt at redhat.com> 3.1.0_fc-11
- Bump release for FC4 update.

elfutils-0.111-1
----------------
* Thu Jul 28 2005 Roland McGrath <roland at redhat.com> - 0.111-1
- update to 0.111
  - libdwfl library now merged into libdw

epiphany-1.7.3-1
----------------
* Tue Jul 26 2005 Christopher Aillon <caillon at redhat.com> - 1.7.3-1
- Update to 1.7.3

evolution-2.3.6-1
-----------------
* Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.6-1
- 2.3.6
- Bump evolution-data-server requirement to 1.3.6 (needed for 
  CAL_STATIC_CAPABILITY_HAS_UNACCEPTED_MEETING)
- Removed libgal2[-devel] dependencies; the code has been moved into the 
  evolution tarball

* Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-2
- added experimental patch to port ETable printing to use Pango (#150458)

* Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-1
- 2.3.5.1
- Update evo_major from 2.2 to 2.4
- Updated evo-calendar-print-with-pango- patch from version 4 to 5
- Removed Patch105: evolution-2.2.2-fix-new-mail-notify.patch as configure.in
  in this branch tests for existance for dbus-glib-1, rather than max-version.
- Removed Patch801: gb-309138-attach-48417-fix-evo-conduit-memleaks.patch as
  this is now in upstream tarball.
- Removed evolution-calendar-importers and evolution-addressbook-importers
  directories.
- Updated evolution-2.2.2-no-gnome-common.patch to include a patch to rename
  mozilla-nspr to nspr

evolution-data-server-1.3.6-1
-----------------------------
* Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 1.3.6-1
- 1.3.6

gimp-2:2.2.8-2
--------------
* Thu Jul 28 2005 Nils Philippsen <nphilipp at redhat.com>
- fix gimptool manpage symlink

gnupg-1.4.2-1
-------------
* Wed Jul 27 2005 Nalin Dahyabhai <nalin at redhat.com> 1.4.2-1
- update to 1.4.2

gtk2-2.7.4-1
------------
* Thu Jul 28 2005 Owen Taylor <otaylor at redhat.com> 2.7.4-1
- Update to 2.7.4

httpd-2.0.54-12
---------------
* Thu Jul 28 2005 Joe Orton <jorton at redhat.com> 2.0.54-12
- drop broken epoch deps

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_43rh
------------------------------------------
* Thu Jul 28 2005 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-40jpp_43rh
- Upgrade bootstrap ecj to pick up classpath parser fix.
- Import java-gcj-compat 1.0.36.

jonas-0:4.3.3-1jpp_7fc
----------------------
* Thu Jul 28 2005 Gary Benson <gbenson at redhat.com> - 4.3.3-1jpp_7fc
- Remove even more jarfiles from the tarball.
- Bundle a binary ews rebuilt with our axis (sorry).

* Thu Jul 28 2005 Andrew Haley <aph at redhat.com>
- Build the disabled examples.
- Fix classpaths in ow_jonas_bootstrap.jar.

* Mon Jul 25 2005 Gary Benson <gbenson at redhat.com>
- Don't bundle tomcat's jarfiles.

kernel-2.6.12-1.1441_FC5
------------------------
* Thu Jul 28 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git9

* Thu Jul 28 2005 David Woodhouse <dwmw2 at redhat.com>
- Enable i8042 and Amiga partitions on PPC (for Pegasos II, CHRP)

* Wed Jul 27 2005 Dave Jones <davej at redhat.com>
- 2.6.13-rc3-git8

libwmf-0.2.8.4-1
----------------
* Thu Jul 28 2005 Caolan McNamara <caolanm at redhat.com> 0.2.8.4-1
- get patches merged upstream
- drop integrated libwmf-0.2.8.3-warnings.patch
- drop integrated libwmf-0.2.8.3-noextras.patch
- drop integrated libwmf-0.2.8.3-rh154813.patch

pam-0.80-5
----------
* Thu Jul 28 2005 Tomas Mraz <tmraz at redhat.com> 0.80-5
- fix NULL dereference in pam_userdb (#164418)

pango-1.9.1-1
-------------
* Thu Jul 28 2005 Owen Taylor <otaylor at redhat.com> 1.9.1-1
- Update to 1.9.1

* Tue Jun 21 2005 Matthias Clasen <mclasen at redhat.com> 
- Add a missing requires

pygtk2-2.7.1-1
--------------
* Wed Jul 27 2005 Mark McLoughlin <markmc at redhat.com> 2.7.1-1
- Update to 2.7.1

rsync-2.6.6-2
-------------
* Thu Jul 28 2005 Jay Fenlason <fenlason at redhat.com> 2.6.6-2
- New upstream release.  See the NEWS file for details.

selinux-policy-strict-1.25.3-8
------------------------------
* Thu Jul 28 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-8
- Fixes for cups, hwclock, system_passwd, samba_net

selinux-policy-targeted-1.25.3-8
--------------------------------
* Thu Jul 28 2005 Dan Walsh <dwalsh at redhat.com> 1.25.3-8
- Fixes for cups, hwclock, system_passwd, samba_net

systemtap-0.2-1
---------------
* Fri Jul 29 2005 Roland McGrath <roland at redhat.com> - 0.2-1
- New version 0.2, requires elfutils 0.111

* Mon Jul 25 2005 Roland McGrath <roland at redhat.com>
- Clean up spec file, build bundled elfutils.

* Thu Jul 21 2005 Martin Hunt <hunt at redhat.com>
- Set Version to use version from autoconf.
- Fix up some of the path names.
- Add Requires and BuildRequires.

xorg-x11-6.8.2-44
-----------------
* Wed Jul 27 2005 Kristian H??gsberg <krh at redhat.com> 6.8.2-44
- Update xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch to
  fix all occurrences of direct PCI config space access.

* Thu Jul 14 2005 Mike A. Harris <mharris at redhat.com>
- Fix FC5 spec file typo for virtual libGL Requires in -devel subpackage

Broken deps for i386
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.i386 requires libpcap.so.0.9.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.i386 requires libpcap.so.0.9.1
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.ppc requires libpcap.so.0.9.1
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.ppc requires libpcap.so.0.9.1
	ethereal-gnome - 0.10.11-4.ppc requires libpcap.so.0.9.1
	evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	dhcp - 10:3.0.3rc1-1.ia64 requires kernel >= 0:2.2.18
	gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	rgmanager - 1.9.31-3.ia64 requires ccs
	ppp - 2.4.3-2.1.ia64 requires libpcap.so.0.9.1()(64bit)
	nfs-utils - 1.0.7-10.ia64 requires kernel >= 0:2.2.14
	pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	quota - 1:3.12-6.ia64 requires kernel >= 0:2.4
	sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21
	arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6
	xorg-x11 - 6.8.2-44.ia64 requires kernel-drm = 0:4.3.0
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11
	ethereal - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	ethereal-gnome - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit)
	lvm2 - 2.01.13-1.0.ia64 requires kernel >= 0:2.6



Broken deps for x86_64
----------------------------------------------------------
	evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	ethereal-gnome - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.x86_64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for s390x
----------------------------------------------------------
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10
	libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	ppp - 2.4.3-2.1.s390x requires libpcap.so.0.9.1()(64bit)
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	ethereal - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	dhcp - 10:3.0.3rc1-1.s390x requires kernel >= 0:2.2.18
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	ethereal-gnome - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit)
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)



Broken deps for s390
----------------------------------------------------------
	ethereal-gnome - 0.10.11-4.s390 requires libpcap.so.0.9.1
	ppp - 2.4.3-2.1.s390 requires libpcap.so.0.9.1
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	ethereal - 0.10.11-4.s390 requires libpcap.so.0.9.1
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	dhcp - 10:3.0.3rc1-1.s390 requires kernel >= 0:2.2.18
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10



Broken deps for ppc64
----------------------------------------------------------
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	ppp - 2.4.3-2.1.ppc64 requires libpcap.so.0.9.1()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	ethereal - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)





From nphilipp at redhat.com  Fri Jul 29 11:44:48 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 29 Jul 2005 13:44:48 +0200
Subject: No more right click terminal
In-Reply-To: <42D3FBD1.4090409@mesias.co.uk>
References: <1121143049.3521.16.camel@localhost.localdomain>
	<42D39DD9.8070106@mesias.co.uk>  <42D3FBD1.4090409@mesias.co.uk>
Message-ID: <1122637489.28527.20.camel@gibraltar.stuttgart.redhat.com>

On Tue, 2005-07-12 at 18:20 +0100, Cam wrote:
> > I used that desktop menu, but I will now try to configure ctrl-shift-T 
> > to open a new terminal. It's the same key sequence to open a new tab in 
> > a terminal... Hope that can be made to work.
> 
> Well that didn't have the desired effect. The ctrl-shift-t for terminal 
> worked but eclipsed the ctrl-shift-t meaning 'new tab' in the terminal.
> 
> How much coding would be involved in adding a 'new terminal or tab in 
> terminal' keyboard shortcut? Or is that too KDE-ish and useful for Gnome?

I have done the right thing(tm) quite a while ago, i.e. I mapped
Shift+Ctrl+N for "new terminal" which happens to be the short cut in the
terminal itself as well ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From dwmw2 at infradead.org  Fri Jul 29 16:17:31 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 29 Jul 2005 17:17:31 +0100
Subject: PPC kernels: More Pegasos II-friendly kernel config
In-Reply-To: <42DB1349.2080300@starhub.net.sg>
References: <42DB1349.2080300@starhub.net.sg>
Message-ID: <1122653852.28128.123.camel@hades.cambridge.redhat.com>

On Mon, 2005-07-18 at 10:26 +0800, RChan wrote:
> While Pegasos II is not officially support as a PPC platform, some
> minor kernel tweaks would make it more friendly out-of-the-box for
> Pegasos II hackers. Would the maintainers kindly consider the
> following changes:

These are done. The rawhide kernel is running on my Pegasos. The rawhide
userspace even works as long as I don't let ld.so get prelinked, and
with today's update to binutils I think we might have firefox and
openoffice.org back again for PPC.

> 2. (This part is hard, I'm not sure I understand the issues myself -
> it's necessary to avoid Pegasos II people from having to rebuild from
> kernel source.) Pegasos II needs a zImage.initrd.chrp kernel to boot
> (i.e. a combined zImage.chrp & initrd) instead of a separate vmlinux +
> initrd, therefore some additional object files need to be distributed
> with the kernel package. I do not understand exactly why yaboot
> (patched with Amiga partition support) does not work with separate
> vmlinux and initrd on Pegasos II so at the moment zImage.initrd.chrp
> is needed.

The problem seems to be that the OF on Pegasos returns zero from its
'claim' method instead of -1 to indicate failure.

By using a combined image you just happen to make sure the first attempt
at allocating memory for it succeeds. Thus yaboot doesn't load the image
to location 00000000 and crash the machine in the process.

A simple workaround (below) in yaboot's prom_claim() function makes it
work properly on the Pegasos, although I'm not sure it's really
something we should do in the general case -- it would be better to fix
the Pegasos SmartFirmware to conform to the OF spec.

We also need to make ybin deal with an ext2-formatted boot partition
(which is simple enough), make a suitable FORTH boot script, and make
nvsetenv work on Pegasos. And probably some more when we get to that
point, as ever... :)

--- prom.c~     2003-11-04 09:13:17.000000000 +0000
+++ prom.c      2005-07-29 12:28:23.000000000 +0100
@@ -547,7 +547,10 @@ prom_sleep (int seconds)
 void *
 prom_claim (void *virt, unsigned int size, unsigned int align)
 {
-     return call_prom ("claim", 3, 1, virt, size, align);
+     void *ret = call_prom ("claim", 3, 1, virt, size, align);
+     if (virt && !ret)
+         ret = (void *)-1;
+     return ret;
 }

 void



-- 
dwmw2



From ldave at droberts.com  Sat Jul 30 00:06:50 2005
From: ldave at droberts.com (Dave Roberts)
Date: Fri, 29 Jul 2005 17:06:50 -0700
Subject: Exec-shield and memory randomization
Message-ID: <1122682010.4422.74.camel@linux.droberts.com>

Can somebody please point me at a good resource for understanding how
exec-shield and memory randomization work?

Specifically, I'm trying to understand the randomize_va_space variable
in /proc/sys/kernel/.

Is randomize_va_space independent of /proc/sys/kernel/exec-shield? That
is, if I "echo 0 > /proc/sys/kernel/exec-shield", I would have thought
that would also turn off memory randomization, but that doesn't seem to
be the case. Are things supposed to work that way, or am I goofing
something up?

Finally, is there a way to disable randomization on a per-binary basis
(with an ELF flag or lack thereof)? I seem have a binary (sbcl) that
doesn't like memory randomization. Rather than turn it off globally, I'd
rather just mark the binary as incompatible with it.

Thanks,

-- 
Dave Roberts <ldave at droberts.com>



From buildsys at redhat.com  Sat Jul 30 11:14:08 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 30 Jul 2005 07:14:08 -0400
Subject: rawhide report: 20050730 changes
Message-ID: <200507301114.j6UBE8Do023760@porkchop.devel.redhat.com>

 

 
Updated Packages:

NetworkManager-0.4-34.cvs20050729
---------------------------------
* Fri Jul 29 2005 Ray Strode  <rstrode at redhat.com> - 0.4-34.cvs20050729
- Update to latest CVS to get fix for bug 165683.

* Mon Jul 11 2005 Dan Williams <dcbw at redhat.com> - 0.4-34.cvs20050629
- Move pkgconfig file to devel package (#162316, thanks to Michael Schwendt)

audit-0.9.20-1
--------------
* Fri Jul 29 2005 Steve Grubb <sgrubb at redhat.com> 0.9.20-1
- Fix ausearch to handle no audit log better
- Fix auditctl blank line handling
- Trim trailing '/' from file system watches in auditctl
- Catch cases where parameter was passed without option being given to auditctl
- Add CAPP sample configuration

* Thu Jul 14 2005 Steve Grubb <sgrubb at redhat.com> 0.9.19-1
- ausearch remove debug code

* Thu Jul 14 2005 Steve Grubb <sgrubb at redhat.com> 0.9.18-1
- auditd message formatter use MAX_AUDIT_MESSAGE_LENGTH to prevent clipping

dhcp-11:3.0.3-1
---------------
* Fri Jul 29 2005 Jason Vas Dias <jvdias at redhat.com> 11:3.0.3-1
- Upgrade to upstream version 3.0.3 
- Don't apply the 'default boot file server' patch: legacy
  dhcp behaviour broke RFC 2131, which requires that the siaddr
  field only be non-zero if the next-server or tftp-server-name
  options are specified.
- Try removing the 1-5 second wait on dhclient startup altogether.
- fix bug 163367: supply default configuration file for dhcpd

distcache-1.4.5-11
------------------
* Fri Jul 29 2005 Joe Orton <jorton at redhat.com> 1.4.5-11
- add distcache user in post script, uid 93
- run daemons as distcache user rather than nobody

elfutils-0.111-2
----------------
* Fri Jul 29 2005 Roland McGrath <roland at redhat.com> - 0.111-2
- update portability patch

evolution-2.3.6.1-1
-------------------
* Fri Jul 29 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.6.1-1
- 2.3.6.1

evolution-data-server-1.3.6.1-1
-------------------------------
* Fri Jul 29 2005 David Malcolm <dmalcolm at redhat.com> - 1.3.6.1-1
- 1.3.6.1

firefox-1.1-0.2.5.deerpark.alpha2
---------------------------------
* Fri Jul 29 2005 Christopher Aillon <caillon at redhat.com> 1.1-0.2.5.deerpark.alpha2
- Re-enable ppc now that its binutils are fixed.
- Disable SVG and canvas again.  The in-tree copy does not build against new pango.
- When clicking a link and going back via history, don't keep the link focused.

gcc-4.0.1-6
-----------
* Fri Jul 29 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.1-6
- update from CVS
  - PRs c++/22545, c/20187, c/22589, c/23106, debug/20161,
	middle-end/21362, rtl-opt/22619, target/17692, target/19885
- add -msecure-plt support on ppc32, enable it by default
- add testcase for ppc32 problem with .got2 relocs against discarded
  sections (PR target/17828)

* Wed Jul 27 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.1-5
- update from CVS
  - PRs tree-optimization/22591, fortran/16940, libfortran/22570,
	libstdc++/23053, middle-end/16719, middle-end/18421,
	target/21149, target/22576
- fix fortran EQUIVALENCE handling with substrings (#160853,
  PRs fortran/18833, fortran/20850)
- improve fortran diagnostics for comparison of logicals (Volker Reichelt,
  PR fortran/22503)
- fix GCSE hoisting (Richard Sandiford, PR rtl-optimization/22167)
- add BuildRequires that ensure glibc{,-devel} is installed for
  both multilib arches where needed for GCC build (#114601)

glibc-2.3.90-7
--------------
* Fri Jul 29 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-7
- update from CVS
- do some poor man's stack guard randomization even without
  the costly --enable-stackguard-randomization
- rebuilt with new GCC to make it use -msecure-plt on PPC32

howl-logger-0:0.1.8-1jpp_3fc
----------------------------
* Fri Jul 29 2005 Gary Benson <gbenson at redhat.com> 0:0.1.8-1jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

nanoxml-0:2.2.3-3jpp_3fc
------------------------
* Fri Jul 29 2005 Gary Benson <gbenson at redhat.com> - 0:2.2.3-3jpp_3fc
- BC-compile.

oldkilim-0:1.1.3-2jpp_3fc
-------------------------
* Fri Jul 29 2005 Gary Benson <gbenson at redhat.com> 0:1.1.3-2jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm (also BC-compiles tools).

p6spy-0:1.3-2jpp_3fc
--------------------
* Fri Jul 29 2005 Gary Benson <gbenson at redhat.com> 0:1.3-2jpp_3fc
- Build on ia64, ppc64, s390 and s390x.
- Switch to aot-compile-rpm.

prelink-0.3.5-2
---------------
* Fri Jul 29 2005 Jakub Jelinek <jakub at redhat.com> 0.3.5-2
- on ppc32 handle -mbss-plt .got sections created with -msecure-plt
  capable binutils (#164615)

udev-063-3
----------
* Thu Jul 28 2005 Harald Hoyer <harald at redhat.com> - 063-3
- changed "SYMLINK=" to "SYMLINK+="

xorg-x11-6.8.2-45
-----------------
* Fri Jul 29 2005 Kristian H??gsberg <krh at redhat.com> 6.8.2-45
- Disable xorg-x11-6.8.2-libvgahw-workaround-rh161242.patch and
  rebuild with gcc-4.0.1-4 which has a workaround for the gcc
  over-optimization bug.

yaboot-1.3.13-0.2
-----------------
* Fri Jul 22 2005 Paul Nasrat <pnasrat at redhat.com> - 1.3.13-0.2
- Workaround claim bug in Pegasos SmartFirmware
- Handle ext2 boot partition

Broken deps for i386
----------------------------------------------------------
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.i386 requires libpcap.so.0.9.1
	evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.i386 requires libpcap.so.0.9.1
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5



Broken deps for ia64
----------------------------------------------------------
	ethereal-gnome - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6
	evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit)
	gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2
	pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
	gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6
	dhcp - 11:3.0.3-1.ia64 requires kernel >= 0:2.2.18
	quota - 1:3.12-6.ia64 requires kernel >= 0:2.4
	lvm2 - 2.01.13-1.0.ia64 requires kernel >= 0:2.6
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	ethereal - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11
	ppp - 2.4.3-2.1.ia64 requires libpcap.so.0.9.1()(64bit)
	nfs-utils - 1.0.7-10.ia64 requires kernel >= 0:2.2.14
	sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0
	rgmanager - 1.9.31-3.ia64 requires ccs
	xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3



Broken deps for ppc64
----------------------------------------------------------
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)
	ethereal-gnome - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	ethereal - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	ppp - 2.4.3-2.1.ppc64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)



Broken deps for ppc
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.ppc requires libpcap.so.0.9.1
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	ethereal-gnome - 0.10.11-4.ppc requires libpcap.so.0.9.1
	ethereal - 0.10.11-4.ppc requires libpcap.so.0.9.1
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16



Broken deps for s390x
----------------------------------------------------------
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	ethereal-gnome - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit)
	dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	ethereal - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0
	prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10
	ppp - 2.4.3-2.1.s390x requires libpcap.so.0.9.1()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	ethereal - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit)
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	ppp - 2.4.3-2.1.x86_64 requires libpcap.so.0.9.1()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)



Broken deps for s390
----------------------------------------------------------
	ethereal-gnome - 0.10.11-4.s390 requires libpcap.so.0.9.1
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	ethereal - 0.10.11-4.s390 requires libpcap.so.0.9.1
	ppp - 2.4.3-2.1.s390 requires libpcap.so.0.9.1
	evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10





From arjanv at redhat.com  Sat Jul 30 12:35:25 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 30 Jul 2005 08:35:25 -0400
Subject: Exec-shield and memory randomization
In-Reply-To: <1122682010.4422.74.camel@linux.droberts.com>
References: <1122682010.4422.74.camel@linux.droberts.com>
Message-ID: <1122726925.3388.15.camel@localhost.localdomain>

setarch has an -R option to start the binary without randomisation.


> Finally, is there a way to disable randomization on a per-binary basis
> (with an ELF flag or lack thereof)? I seem have a binary (sbcl) that
> doesn't like memory randomization. Rather than turn it off globally, I'd
> rather just mark the binary as incompatible with it.

I wonder why the app breaks; randomisation doesn't do anything weird at
all, in fact even before this stuff got in there was some extend of
randomisation already.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050730/09b590b7/attachment.sig>

From bernie at develer.com  Sat Jul 30 15:04:43 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Sat, 30 Jul 2005 17:04:43 +0200
Subject: rpm with sqlite
Message-ID: <42EB970B.70904@develer.com>

Hello,

is there a known issue with RPM's sqlite backend?

I've switched my RPM database to sqlite and now
I see strange dependency problems when installing
new packages.

For instance:

  # rpm -F xorg-x11-*
  error: Failed dependencies:
          /usr/sbin/chkfontpath is needed by xorg-x11-6.8.2-45.x86_64
  # ls -l /usr/sbin/chkfontpath
  -rwxr-xr-x  1 root root 17288 Mar  3 21:03 /usr/sbin/chkfontpath
  # rpm -ql chkfontpath
  /usr/sbin/chkfontpath
  /usr/share/man/man8/chkfontpath.8.gz

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From tibbs at math.uh.edu  Sat Jul 30 15:29:28 2005
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Sat, 30 Jul 2005 10:29:28 -0500
Subject: Exec-shield and memory randomization
In-Reply-To: <1122726925.3388.15.camel@localhost.localdomain> (Arjan van de
	Ven's message of "Sat, 30 Jul 2005 08:35:25 -0400")
References: <1122682010.4422.74.camel@linux.droberts.com>
	<1122726925.3388.15.camel@localhost.localdomain>
Message-ID: <ufamzo4b9d3.fsf@epithumia.math.uh.edu>

>>>>> "AvdV" == Arjan van de Ven <arjanv at redhat.com> writes:

AvdV> I wonder why the app breaks; randomisation doesn't do anything
AvdV> weird at all, in fact even before this stuff got in there was
AvdV> some extend of randomisation already.

Haven't Lisp systems historically been problematic with respect to any
changes in memory layout?

 - J<



From seandarcy2 at gmail.com  Sat Jul 30 17:05:55 2005
From: seandarcy2 at gmail.com (sean)
Date: Sat, 30 Jul 2005 13:05:55 -0400
Subject: rawhide report: 20050730 changes
In-Reply-To: <200507301114.j6UBE8Do023760@porkchop.devel.redhat.com>
References: <200507301114.j6UBE8Do023760@porkchop.devel.redhat.com>
Message-ID: <dcgc1j$sma$1@sea.gmane.org>

Build System wrote:
>  
............
> 
> evolution-2.3.6.1-1
> -------------------
> * Fri Jul 29 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.6.1-1
> - 2.3.6.1
> 
> evolution-data-server-1.3.6.1-1
> -------------------------------
> * Fri Jul 29 2005 David Malcolm <dmalcolm at redhat.com> - 1.3.6.1-1
> - 1.3.6.1
> 
........

   Updating  : evolution 
##################### [ 20/140]
I/O warning : failed to load external entity 
"/etc/gconf/schemas/apps_evolution_addressboo k-2.2.schemas"
Failed to open 
`/etc/gconf/schemas/apps_evolution_addressbook-2.2.schemas': 
No such file o r directory
I/O warning : failed to load external entity 
"/etc/gconf/schemas/apps_evolution_calendar-2 .2.schemas"
Failed to open 
`/etc/gconf/schemas/apps_evolution_calendar-2.2.schemas': No 
such file or d irectory
I/O warning : failed to load external entity 
"/etc/gconf/schemas/apps_evolution_shell-2.2. schemas"
Failed to open 
`/etc/gconf/schemas/apps_evolution_shell-2.2.schemas': No 
such file or dire ctory
I/O warning : failed to load external entity 
"/etc/gconf/schemas/evolution-mail-2.2.schema s"
Failed to open 
`/etc/gconf/schemas/evolution-mail-2.2.schemas': No such 
file or directory

??



From dmalcolm at redhat.com  Sat Jul 30 17:18:32 2005
From: dmalcolm at redhat.com (Dave Malcolm)
Date: Sat, 30 Jul 2005 13:18:32 -0400
Subject: rawhide report: 20050730 changes
In-Reply-To: <dcgc1j$sma$1@sea.gmane.org>
References: <200507301114.j6UBE8Do023760@porkchop.devel.redhat.com>
	<dcgc1j$sma$1@sea.gmane.org>
Message-ID: <1122743912.5172.1.camel@localhost.localdomain>

On Sat, 2005-07-30 at 13:05 -0400, sean wrote:
> Build System wrote:
> >  
> ............
> > 
> > evolution-2.3.6.1-1
> > -------------------
> > * Fri Jul 29 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.6.1-1
> > - 2.3.6.1
> > 
> > evolution-data-server-1.3.6.1-1
> > -------------------------------
> > * Fri Jul 29 2005 David Malcolm <dmalcolm at redhat.com> - 1.3.6.1-1
> > - 1.3.6.1
> > 
> ........
> 
>    Updating  : evolution 
> ##################### [ 20/140]
> I/O warning : failed to load external entity 
> "/etc/gconf/schemas/apps_evolution_addressboo k-2.2.schemas"
> Failed to open 
> `/etc/gconf/schemas/apps_evolution_addressbook-2.2.schemas': 
> No such file o r directory
> I/O warning : failed to load external entity 
> "/etc/gconf/schemas/apps_evolution_calendar-2 .2.schemas"
> Failed to open 
> `/etc/gconf/schemas/apps_evolution_calendar-2.2.schemas': No 
> such file or d irectory
> I/O warning : failed to load external entity 
> "/etc/gconf/schemas/apps_evolution_shell-2.2. schemas"
> Failed to open 
> `/etc/gconf/schemas/apps_evolution_shell-2.2.schemas': No 
> such file or dire ctory
> I/O warning : failed to load external entity 
> "/etc/gconf/schemas/evolution-mail-2.2.schema s"
> Failed to open 
> `/etc/gconf/schemas/evolution-mail-2.2.schemas': No such 
> file or directory
> 
Thanks; this is:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164622

Should be fixed in tomorrow's rawhide



From paul at all-the-johnsons.co.uk  Sat Jul 30 17:27:08 2005
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Sat, 30 Jul 2005 18:27:08 +0100
Subject: rawhide report: 20050730 changes
In-Reply-To: <1122743912.5172.1.camel@localhost.localdomain>
References: <200507301114.j6UBE8Do023760@porkchop.devel.redhat.com>
	<dcgc1j$sma$1@sea.gmane.org>
	<1122743912.5172.1.camel@localhost.localdomain>
Message-ID: <1122744428.4084.3.camel@localhost>

Hi,

> Thanks; this is:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164622
> 
> Should be fixed in tomorrow's rawhide

Any sign of a fix on #164490?

TTFN

Paul

-- 
"Some people will do anything for a woman in uniform" - The Doctor -
Unregenerate (Big Finish audio)



From ldave at droberts.com  Sat Jul 30 18:54:01 2005
From: ldave at droberts.com (Dave Roberts)
Date: Sat, 30 Jul 2005 11:54:01 -0700
Subject: Exec-shield and memory randomization
In-Reply-To: <ufamzo4b9d3.fsf@epithumia.math.uh.edu>
References: <1122682010.4422.74.camel@linux.droberts.com>
	<1122726925.3388.15.camel@localhost.localdomain>
	<ufamzo4b9d3.fsf@epithumia.math.uh.edu>
Message-ID: <1122749641.4422.78.camel@linux.droberts.com>

On Sat, 2005-07-30 at 10:29 -0500, Jason L Tibbitts III wrote:
> >>>>> "AvdV" == Arjan van de Ven <arjanv at redhat.com> writes:
> 
> AvdV> I wonder why the app breaks; randomisation doesn't do anything
> AvdV> weird at all, in fact even before this stuff got in there was
> AvdV> some extend of randomisation already.
> 
> Haven't Lisp systems historically been problematic with respect to any
> changes in memory layout?

It seems like it. I don't know enough about SBCL internals (yet), to
know exactly why this it's tripping up SBCL. My hunch is that sbcl uses
certain memory areas for storing different types of data and can
therefore use some sort of pointer arithmetic on some bits of a pointer
to quickly determine what type is being pointed at. That's just a hunch,
however.

In general, most of the Lisp-like systems seem to want more control over
memory placements.

-- 
Dave Roberts <ldave at droberts.com>



From ldave at droberts.com  Sat Jul 30 19:10:04 2005
From: ldave at droberts.com (Dave Roberts)
Date: Sat, 30 Jul 2005 12:10:04 -0700
Subject: Exec-shield and memory randomization
In-Reply-To: <1122726925.3388.15.camel@localhost.localdomain>
References: <1122682010.4422.74.camel@linux.droberts.com>
	<1122726925.3388.15.camel@localhost.localdomain>
Message-ID: <1122750604.4422.93.camel@linux.droberts.com>

On Sat, 2005-07-30 at 08:35 -0400, Arjan van de Ven wrote:
> setarch has an -R option to start the binary without randomisation.

Thanks, Arjan. I appreciate your help. I have a few follow-up questions:

Does setarch set the info in a persistent fashion? I'm reading the man
page for it (under FC3) and I can't quite tell what it does (setarch in
general, but it also doesn't document the -R option, BTW).

Hmmm.... in fact, trying it now on FC3, it doesn't seem to support that
option. Is -R only in FC4 right now? If so, there's probably a need to
release another setarch that supports that option for FC3, since it
looks like the latest FC3 kernel (2.6.12-1.1372_FC3) has
randomize_va_space defaulting to 1.

Also, there's a strange thing that I noticed when trying to debug this a
couple days ago: for some reason, older binaries that I built 3 or 4
months ago seem to work fine, while newer binaries don't. Did something
in gcc change that makes the old ones work and the new ones not? (like
GCC setting some compatibility bit in the ELF header differently in
newer GCCs).

Finally, is randomize_va_space supposed to be controlled by exec-shield?
When debugging, I first set exec-shield to 0, but that didn't seem to
have an effect. It was only when randomize_va_space get set to 0 that
things started working. That it, they seem independent, but most of the
documentation on exec-shield I have seen seems to suggest that turning
off exec-shield should turn off just about everything and leave you with
a pretty standard system, ala the pre-exec-shield days. Is that no
longer true?

-- 
Dave Roberts <ldave at droberts.com>



From rodd at clarkson.id.au  Sun Jul 31 04:12:53 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 31 Jul 2005 14:12:53 +1000
Subject: Firefox seems to crash on middle clicks to various parts of the
	browser window.
Message-ID: <1122783173.3277.6.camel@localhost.localdomain>

Anyone else seeing situations where firefox (deerpark) is crashing when
you middle click on things?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164726


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From rodd at clarkson.id.au  Sun Jul 31 04:18:11 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 31 Jul 2005 14:18:11 +1000
Subject: rawhide report: 20050729 changes
In-Reply-To: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
References: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
Message-ID: <1122783491.3277.10.camel@localhost.localdomain>

On Fri, 2005-07-29 at 07:21 -0400, Build System wrote:

> evolution-2.3.6-1
> -----------------
> * Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.6-1
> - 2.3.6
> - Bump evolution-data-server requirement to 1.3.6 (needed for 
>   CAL_STATIC_CAPABILITY_HAS_UNACCEPTED_MEETING)
> - Removed libgal2[-devel] dependencies; the code has been moved into the 
>   evolution tarball
> 
> * Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-2
> - added experimental patch to port ETable printing to use Pango (#150458)
> 
> * Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-1
> - 2.3.5.1
> - Update evo_major from 2.2 to 2.4
> - Updated evo-calendar-print-with-pango- patch from version 4 to 5
> - Removed Patch105: evolution-2.2.2-fix-new-mail-notify.patch as configure.in
>   in this branch tests for existance for dbus-glib-1, rather than max-version.
> - Removed Patch801: gb-309138-attach-48417-fix-evo-conduit-memleaks.patch as
>   this is now in upstream tarball.
> - Removed evolution-calendar-importers and evolution-addressbook-importers
>   directories.
> - Updated evolution-2.2.2-no-gnome-common.patch to include a patch to rename
>   mozilla-nspr to nspr

Evolution doesn't seem to want to do IMAP any more.  I've tried both the
IMAP options and neither seems able to open the mail account.  Until
this release IMAP had been working fine for me.

Anyone else seeing this?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164727


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From rodd at clarkson.id.au  Sun Jul 31 04:22:07 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 31 Jul 2005 14:22:07 +1000
Subject: rawhide report: 20050729 changes
In-Reply-To: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
References: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
Message-ID: <1122783728.3277.16.camel@localhost.localdomain>

On Fri, 2005-07-29 at 07:21 -0400, Build System wrote:

> cairo-0.6.0-1
> -------------
> * Thu Jul 28 2005 Owen Taylor <otaylor at devserv.devel.redhat.com> 0.6.0-1
> - Update to cairo-0.6.0

<snip>

> gtk2-2.7.4-1
> ------------
> * Thu Jul 28 2005 Owen Taylor <otaylor at redhat.com> 2.7.4-1
> - Update to 2.7.4

<snip>

> pango-1.9.1-1
> -------------
> * Thu Jul 28 2005 Owen Taylor <otaylor at redhat.com> 1.9.1-1
> - Update to 1.9.1
> 
> * Tue Jun 21 2005 Matthias Clasen <mclasen at redhat.com> 
> - Add a missing requires

The font rendering with the current version of cairo and pango seem to
be fantastic.  Vastly improved (in a very subjective way).

Well done Owen and thank you very much.


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From Nicolas.Mailhot at laPoste.net  Sun Jul 31 07:49:23 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 31 Jul 2005 09:49:23 +0200
Subject: rawhide report: 20050729 changes
In-Reply-To: <1122783728.3277.16.camel@localhost.localdomain>
References: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
	<1122783728.3277.16.camel@localhost.localdomain>
Message-ID: <1122796164.2633.2.camel@rousalka.dyndns.org>

Le dimanche 31 juillet 2005 ? 14:22 +1000, Rodd Clarkson a ?crit :
> On Fri, 2005-07-29 at 07:21 -0400, Build System wrote:
> 
> > cairo-0.6.0-1
> > -------------
> > * Thu Jul 28 2005 Owen Taylor <otaylor at devserv.devel.redhat.com> 0.6.0-1
> > - Update to cairo-0.6.0
> 
> <snip>
> 
> > gtk2-2.7.4-1
> > ------------
> > * Thu Jul 28 2005 Owen Taylor <otaylor at redhat.com> 2.7.4-1
> > - Update to 2.7.4
> 
> <snip>
> 
> > pango-1.9.1-1
> > -------------
> > * Thu Jul 28 2005 Owen Taylor <otaylor at redhat.com> 1.9.1-1
> > - Update to 1.9.1
> > 
> > * Tue Jun 21 2005 Matthias Clasen <mclasen at redhat.com> 
> > - Add a missing requires
> 
> The font rendering with the current version of cairo and pango seem to
> be fantastic.  Vastly improved (in a very subjective way).
> 
> Well done Owen and thank you very much.

Seems so here. The regression I reported back is gone (was still
resting, but since I'm not the only one to see it)

OTOH firefox is very unstable. Dunno if it's the cairo backend or
something else.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050731/2b6dfc97/attachment.sig>

From kms at passback.co.uk  Sun Jul 31 08:56:15 2005
From: kms at passback.co.uk (Keith Sharp)
Date: Sun, 31 Jul 2005 09:56:15 +0100
Subject: rawhide report: 20050729 changes
In-Reply-To: <1122783491.3277.10.camel@localhost.localdomain>
References: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
	<1122783491.3277.10.camel@localhost.localdomain>
Message-ID: <1122800175.25262.1.camel@animal.passback.co.uk>

On Sun, 2005-07-31 at 14:18 +1000, Rodd Clarkson wrote:
> On Fri, 2005-07-29 at 07:21 -0400, Build System wrote:
> 
> > evolution-2.3.6-1
> > -----------------
> > * Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.6-1
> > - 2.3.6
> > - Bump evolution-data-server requirement to 1.3.6 (needed for 
> >   CAL_STATIC_CAPABILITY_HAS_UNACCEPTED_MEETING)
> > - Removed libgal2[-devel] dependencies; the code has been moved into the 
> >   evolution tarball
> > 
> > * Thu Jul 28 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-2
> > - added experimental patch to port ETable printing to use Pango (#150458)
> > 
> > * Mon Jul 25 2005 David Malcolm <dmalcolm at redhat.com> - 2.3.5.1-1
> > - 2.3.5.1
> > - Update evo_major from 2.2 to 2.4
> > - Updated evo-calendar-print-with-pango- patch from version 4 to 5
> > - Removed Patch105: evolution-2.2.2-fix-new-mail-notify.patch as configure.in
> >   in this branch tests for existance for dbus-glib-1, rather than max-version.
> > - Removed Patch801: gb-309138-attach-48417-fix-evo-conduit-memleaks.patch as
> >   this is now in upstream tarball.
> > - Removed evolution-calendar-importers and evolution-addressbook-importers
> >   directories.
> > - Updated evolution-2.2.2-no-gnome-common.patch to include a patch to rename
> >   mozilla-nspr to nspr
> 
> Evolution doesn't seem to want to do IMAP any more.  I've tried both the
> IMAP options and neither seems able to open the mail account.  Until
> this release IMAP had been working fine for me.
> 
> Anyone else seeing this?
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164727

I am not sure if it is the same issue, but Michael Zucchi (author of the
Evolution IMAP code) mentioned in his blog that it is broken in 2.3.6:

	http://blogs.gnome.org/view/zucchi/2005/07/28/0

Keith.



From arjanv at redhat.com  Sun Jul 31 10:16:13 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sun, 31 Jul 2005 12:16:13 +0200
Subject: Exec-shield and memory randomization
In-Reply-To: <ufamzo4b9d3.fsf@epithumia.math.uh.edu>
References: <1122682010.4422.74.camel@linux.droberts.com>
	<1122726925.3388.15.camel@localhost.localdomain>
	<ufamzo4b9d3.fsf@epithumia.math.uh.edu>
Message-ID: <20050731101613.GA29452@devserv.devel.redhat.com>

On Sat, Jul 30, 2005 at 10:29:28AM -0500, Jason L Tibbitts III wrote:
> >>>>> "AvdV" == Arjan van de Ven <arjanv at redhat.com> writes:
> 
> AvdV> I wonder why the app breaks; randomisation doesn't do anything
> AvdV> weird at all, in fact even before this stuff got in there was
> AvdV> some extend of randomisation already.
> 
> Haven't Lisp systems historically been problematic with respect to any
> changes in memory layout?

this isn't a change really; eg what randomisation does can happen anyway if you
do say,
 yum update glibc



From rodd at clarkson.id.au  Sun Jul 31 11:19:17 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 31 Jul 2005 21:19:17 +1000
Subject: rawhide report: 20050729 changes
In-Reply-To: <1122796164.2633.2.camel@rousalka.dyndns.org>
References: <200507291121.j6TBLq3W010558@porkchop.devel.redhat.com>
	<1122783728.3277.16.camel@localhost.localdomain>
	<1122796164.2633.2.camel@rousalka.dyndns.org>
Message-ID: <1122808757.2930.1.camel@localhost.localdomain>

On Sun, 2005-07-31 at 09:49 +0200, Nicolas Mailhot wrote:
> Le dimanche 31 juillet 2005 ? 14:22 +1000, Rodd Clarkson a ?crit :

> > The font rendering with the current version of cairo and pango seem to
> > be fantastic.  Vastly improved (in a very subjective way).
> > 
> > Well done Owen and thank you very much.
> 
> Seems so here. The regression I reported back is gone (was still
> resting, but since I'm not the only one to see it)
> 
> OTOH firefox is very unstable. Dunno if it's the cairo backend or
> something else.

Ah, yes!  I noticed that firefox was a little unstable too.

Here's hoping that's addressed soon. ;-]


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From buildsys at redhat.com  Sun Jul 31 11:27:18 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 31 Jul 2005 07:27:18 -0400
Subject: rawhide report: 20050731 changes
Message-ID: <200507311127.j6VBRI9E020433@porkchop.devel.redhat.com>

 

 
Updated Packages:

evolution-2.3.6.1-2
-------------------
* Sat Jul 30 2005 David Malcolm <dmalcolm at redhat.com> 2.3.6.1-2
- Fixed version numbers in GConf schema files (#164622); added 
  apps-evolution-mail-prompts-checkdefault-2.4.schemas

mozilla-37:1.7.11-1
-------------------
* Fri Jul 29 2005 Christopher Aillon <caillon at redhat.com> 37:1.7.11-1
- Mozilla 1.7.11
- Add patch to make the file chooser modal
- Embedding prompt patches:
  - Don't crash on opening or closing a prompt
  - Better wrapping of long lines
- Display borders for tooltips in embedded code.

yaboot-1.3.13-0.3
-----------------
* Sat Jul 30 2005 David Woodhouse <dwmw2 at redhat.com> - 1.3.13-0.3
- Accept config file path on command line
- Make ofpath work on Pegasos

* Fri Jul 29 2005 David Woodhouse <dwmw2 at redhat.com> - 1.3.13-0.2
- Workaround claim bug in Pegasos SmartFirmware
- Handle ext2 boot partition

* Fri Jul 22 2005 Paul Nasrat <pnasrat at redhat.com> - 1.3.13-0.1
- Upstream 1.3.13
- Add patches on yaboot-1.3.x tree
- Try dropping ppc64 initrd patch

Broken deps for ia64
----------------------------------------------------------
	lvm2 - 2.01.13-1.0.ia64 requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit)
	xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0
	dhcp - 11:3.0.3-1.ia64 requires kernel >= 0:2.2.18
	ethereal-gnome - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	quota - 1:3.12-6.ia64 requires kernel >= 0:2.4
	arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0
	epiphany - 1.7.3-1.ia64 requires mozilla = 37:1.7.10
	devhelp - 0.10-2.ia64 requires mozilla = 37:1.7.10
	gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2
	gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	rgmanager - 1.9.31-3.ia64 requires ccs
	initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit)
	nfs-utils - 1.0.7-10.ia64 requires kernel >= 0:2.2.14
	ppp - 2.4.3-2.1.ia64 requires libpcap.so.0.9.1()(64bit)
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21
	ethereal - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit)
	hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11
	pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
	evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit)



Broken deps for i386
----------------------------------------------------------
	cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3
	GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	epiphany - 1.7.3-1.i386 requires mozilla = 37:1.7.10
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.i386 requires libpcap.so.0.9.1
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5
	gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal - 0.10.11-4.i386 requires libpcap.so.0.9.1
	gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16
	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU
	gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5
	devhelp - 0.10-2.i386 requires mozilla = 37:1.7.10



Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1
	ethereal - 0.10.11-4.ppc requires libpcap.so.0.9.1
	gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16
	evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3
	devhelp - 0.10-2.ppc requires mozilla = 37:1.7.10
	epiphany - 1.7.3-1.ppc requires mozilla = 37:1.7.10
	ethereal-gnome - 0.10.11-4.ppc requires libpcap.so.0.9.1
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.ppc requires libpcap.so.0.9.1



Broken deps for s390
----------------------------------------------------------
	gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16
	prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10
	lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	devhelp - 0.10-2.s390 requires mozilla = 37:1.7.10
	nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0
	nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2
	epiphany - 1.7.3-1.s390 requires mozilla = 37:1.7.10
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0
	ethereal-gnome - 0.10.11-4.s390 requires libpcap.so.0.9.1
	ppp - 2.4.3-2.1.s390 requires libpcap.so.0.9.1
	dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	quota - 1:3.12-6.s390 requires kernel >= 0:2.4
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0
	sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2
	nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14
	ethereal - 0.10.11-4.s390 requires libpcap.so.0.9.1
	evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2
	evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6
	sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21



Broken deps for s390x
----------------------------------------------------------
	selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit)
	sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit)
	ppp - 2.4.3-2.1.s390x requires libpcap.so.0.9.1()(64bit)
	nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14
	devhelp - 0.10-2.s390x requires mozilla = 37:1.7.10
	dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18
	evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit)
	selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit)
	prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10
	lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6
	epiphany - 1.7.3-1.s390x requires mozilla = 37:1.7.10
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit)
	nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit)
	selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2
	sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21
	ethereal - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)
	quota - 1:3.12-6.s390x requires kernel >= 0:2.4
	selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219
	hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11
	libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0
	libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0
	initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6
	hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11
	arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0
	ethereal-gnome - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit)
	ethereal - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	devhelp - 0.10-2.x86_64 requires mozilla = 37:1.7.10
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	ppp - 2.4.3-2.1.x86_64 requires libpcap.so.0.9.1()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit)
	evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit)
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5
	epiphany - 1.7.3-1.x86_64 requires mozilla = 37:1.7.10



Broken deps for ppc64
----------------------------------------------------------
	ppp - 2.4.3-2.1.ppc64 requires libpcap.so.0.9.1()(64bit)
	firstboot - 1.3.43-1.noarch requires system-config-display
	system-config-keyboard - 1.2.6-2.noarch requires pyxf86config
	ppc64-utils - 0.7-9.ppc64 requires yaboot
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	ethereal-gnome - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit)
	system-config-mouse - 1.2.11-1.noarch requires pyxf86config
	ethereal - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit)
	gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5
	gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit)
	gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit)
	jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3
	control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit)





From rodd at clarkson.id.au  Sun Jul 31 11:41:29 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 31 Jul 2005 21:41:29 +1000
Subject: rawhide report: 20050731 changes
In-Reply-To: <200507311127.j6VBRI9E020433@porkchop.devel.redhat.com>
References: <200507311127.j6VBRI9E020433@porkchop.devel.redhat.com>
Message-ID: <1122810089.2930.6.camel@localhost.localdomain>

On Sun, 2005-07-31 at 07:27 -0400, Build System wrote:
<snip>

> Broken deps for i386

<snip>

> 	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1

<snip>

Is this being addressed?

This seems to have become a problem around the 27 of July, but it's a
little strange.  The brokens deps on the 27th report this problem too,
but strangely, ppp wasn't among the updates on that day (unless I'm
looking at the wrong thing).

I'm just a little surprised that this is still an issue after four (or
five) updates.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From mailinglists at andreas-mueller.com  Sun Jul 31 15:58:01 2005
From: mailinglists at andreas-mueller.com (Andreas Mueller)
Date: Sun, 31 Jul 2005 17:58:01 +0200
Subject: rawhide report: 20050731 changes
In-Reply-To: <1122810089.2930.6.camel@localhost.localdomain>
References: <200507311127.j6VBRI9E020433@porkchop.devel.redhat.com>
	<1122810089.2930.6.camel@localhost.localdomain>
Message-ID: <200507311758.02418.mailinglists@andreas-mueller.com>

Rodd Clarkson wrote:
> On Sun, 2005-07-31 at 07:27 -0400, Build System wrote:
> <snip>
>
> > Broken deps for i386
>
> <snip>
>
> > 	ppp - 2.4.3-2.1.i386 requires libpcap.so.0.9.1
>
> <snip>
>
> Is this being addressed?
>
> This seems to have become a problem around the 27 of July, but it's a
> little strange.  The brokens deps on the 27th report this problem
> too, but strangely, ppp wasn't among the updates on that day (unless
> I'm looking at the wrong thing).

libpcap was updated, it is build from the tcpdump src.rpm.

> I'm just a little surprised that this is still an issue after four
> (or five) updates.

I think ppp just needs a rebuild.

Andreas.



From Nicolas.Mailhot at laPoste.net  Sun Jul 31 16:43:26 2005
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 31 Jul 2005 18:43:26 +0200
Subject: [DejaVu-fonts] Re: weird representation for FFFD
In-Reply-To: <1120682021.18405.29.camel@rousalka.dyndns.org>
References: <42C00042.3010307@draigBrady.com>
	<1119882800.5260.141.camel@localhost.localdomain>
	<42C01D5C.6030107@draigBrady.com>
	<7134.192.54.193.35.1120663634.squirrel@rousalka.dyndns.org>
	<42CC0288.3050409@draigBrady.com>
	<1120669332.17357.7.camel@rousalka.dyndns.org>
	<20050706201720.GA92809@stud.fit.vutbr.cz>
	<1120682021.18405.29.camel@rousalka.dyndns.org>
Message-ID: <1122828206.2633.40.camel@rousalka.dyndns.org>

Le mercredi 06 juillet 2005 ? 22:33 +0200, Nicolas Mailhot a ?crit :
> Le mercredi 06 juillet 2005 ? 22:17 +0200, David Jez a ?crit :
> > > Well, Fedora already has its share of ugly fonts with wide unicode
> > > coverage. As we're only talking about a single character here,
> that does
> > > not seem too difficult to create (just add a black diamond to a
> question
> > > mark), I'd suggest you just get it into dejavu and I'll get the
> new
> > > dejavu version into Fedora Extras.
> > > 
> > > If you're quick it'll be available for users by early august.
> >   As you wish...
> 
> James Cloos already proposed to work on it. I must say it's great to
> have a reactive font project instead of packaging and installing
> scores
> of incomplete/different/frozen fonts just to get good glyph coverage.
> 
> And I hope this thread will inspire more people on the CCd lists to
> work
> through dejavu!

The symbol is in dejavu 1.12 which was released today on schedule, and
is now queued in the Fedora Extras build system. (I won't be there to
queue 1.13 though - it'll have to wait)

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050731/2c28e49a/attachment.sig>

From arjanv at redhat.com  Sun Jul 31 17:46:29 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sun, 31 Jul 2005 19:46:29 +0200
Subject: Exec-shield and memory randomization
In-Reply-To: <1122750604.4422.93.camel@linux.droberts.com>
References: <1122682010.4422.74.camel@linux.droberts.com>
	<1122726925.3388.15.camel@localhost.localdomain>
	<1122750604.4422.93.camel@linux.droberts.com>
Message-ID: <1122831990.3286.12.camel@laptopd505.fenrus.org>

> . That it, they seem independent, but most of the
> documentation on exec-shield I have seen seems to suggest that turning
> off exec-shield should turn off just about everything and leave you with
> a pretty standard system, ala the pre-exec-shield days. Is that no
> longer true?

well.. randomisation is now merged upstream....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050731/8513a4e0/attachment.sig>

From rodd at clarkson.id.au  Sun Jul 31 23:05:29 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 01 Aug 2005 09:05:29 +1000
Subject: rawhide report: 20050731 changes
In-Reply-To: <200507311758.02418.mailinglists@andreas-mueller.com>
References: <200507311127.j6VBRI9E020433@porkchop.devel.redhat.com>
	<1122810089.2930.6.camel@localhost.localdomain>
	<200507311758.02418.mailinglists@andreas-mueller.com>
Message-ID: <1122851129.20107.3.camel@localhost.localdomain>

On Sun, 2005-07-31 at 17:58 +0200, Andreas Mueller wrote:
> Rodd Clarkson wrote:
> > Is this being addressed?
> >
> > This seems to have become a problem around the 27 of July, but it's a
> > little strange.  The brokens deps on the 27th report this problem
> > too, but strangely, ppp wasn't among the updates on that day (unless
> > I'm looking at the wrong thing).
> 
> libpcap was updated, it is build from the tcpdump src.rpm.

Ah, HA.  I searched google, but i showed libpcap belonging to libpcap so
that explains that.

> > I'm just a little surprised that this is still an issue after four
> > (or five) updates.
> 
> I think ppp just needs a rebuild.

Presumably isdn4k-utils will need to be rebuilt too.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From reuben-fedora-devel at reub.net  Sun Jul 31 23:10:20 2005
From: reuben-fedora-devel at reub.net (Reuben Farrelly)
Date: Mon, 01 Aug 2005 11:10:20 +1200
Subject: rawhide report: 20050731 changes
In-Reply-To: <1122851129.20107.3.camel@localhost.localdomain>
References: <200507311127.j6VBRI9E020433@porkchop.devel.redhat.com>	<1122810089.2930.6.camel@localhost.localdomain>	<200507311758.02418.mailinglists@andreas-mueller.com>
	<1122851129.20107.3.camel@localhost.localdomain>
Message-ID: <42ED5A5C.1090300@reub.net>

On 1/08/2005 11:05 a.m., Rodd Clarkson wrote:

>>> I'm just a little surprised that this is still an issue after four
>>> (or five) updates.
>> I think ppp just needs a rebuild.
> 
> Presumably isdn4k-utils will need to be rebuilt too.

As does ethereal:

[root at tornado dovecot]# rpm -V ethereal
Unsatisfied dependencies for ethereal-0.10.11-4.i386: libpcap.so.0.9.1

reuben



From ldave at droberts.com  Sun Jul 31 23:27:16 2005
From: ldave at droberts.com (Dave Roberts)
Date: Sun, 31 Jul 2005 16:27:16 -0700
Subject: Exec-shield and memory randomization
In-Reply-To: <1122831990.3286.12.camel@laptopd505.fenrus.org>
References: <1122682010.4422.74.camel@linux.droberts.com>
	<1122726925.3388.15.camel@localhost.localdomain>
	<1122750604.4422.93.camel@linux.droberts.com>
	<1122831990.3286.12.camel@laptopd505.fenrus.org>
Message-ID: <1122852436.4422.104.camel@linux.droberts.com>

On Sun, 2005-07-31 at 19:46 +0200, Arjan van de Ven wrote:
> > . That it, they seem independent, but most of the
> > documentation on exec-shield I have seen seems to suggest that turning
> > off exec-shield should turn off just about everything and leave you with
> > a pretty standard system, ala the pre-exec-shield days. Is that no
> > longer true?
> 
> well.. randomisation is now merged upstream....

I'm not sure I understand. So that means "yes, they are now
independent" ?

So assuming that's the case, what does the kernel look for in
determining whether to turn of randomization on a per-binary basis? In
reading some older materials (like last year's Security Enhancements in
Red Hat Enterprise Linux paper by Drepper), it looked like the presence
of an explicitly executable stack segment in the ELF binary would turn
off all the various exec-shield enhancements, including randomization.
I'm guessing that this is still true for exec-shield, but does anything
now control randomization?

Running readelf and looking at the stack segment shows:

[dave at linux ~]$ readelf -l /usr/bin/sbcl | fgrep STACK
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

which as I understood it means that the stack is being marked as
executable (the "E" in the "RWE" field, right?).

So shouldn't this binary not be getting randomized memory addresses in
any case?

In any case, sorry to be persistent about this stuff. I have no desire
to be a pest. If you can point me to any up-to-date docs on this stuff,
I'd be happy to RTFM. I have been searching for anything I can get my
hands on but have been generally unsuccessful. Everything I read seems
to predate the change of randomization being merged upstream and so
short of reading the patches all myself (which comes next, I suppose), I
haven't found anything particular authoritative about how this works. An
email from yourself would be worth its weight in gold (at least if you
printed it out ;-).

-- 
Dave Roberts <ldave at droberts.com>



From vonbrand at inf.utfsm.cl  Sun Jul 31 23:43:33 2005
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sun, 31 Jul 2005 19:43:33 -0400
Subject: Firefox seems to crash on middle clicks to various parts of the
	browser window. 
In-Reply-To: Your message of "Sun, 31 Jul 2005 14:12:53 +1000."
	<1122783173.3277.6.camel@localhost.localdomain> 
Message-ID: <200507312343.j6VNhXol003892@laptop11.inf.utfsm.cl>

Rodd Clarkson <rodd at clarkson.id.au> wrote:
> Anyone else seeing situations where firefox (deerpark) is crashing when
> you middle click on things?

Yep. Happens at random here.

firefox-1.1-0.2.5.deerpark.alpha2
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164726
> 
> 
> Rodd
> -- 
> "It's a fine line between denial and faith.
>  It's much better on my side"
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list