3:35 p.m.
If you are involved in the development of Fedora Core as a packager,
here is information that will be relevant to you.
FC5test1 devel freeze now November 14th
=======================================
Rawhide is undergoing a large amount of churn as we are preparing for
the switch from monolithic to modular X. Modular X is one of the larger
and more important changes of FC5, meaning we need extensive test
exposure. For this reason the test1 devel freeze has been postponed
until November 14th.
http://fedora.redhat.com/participate/schedule/
Fedora Core 5 Development Schedule has been updated.
http://fedoraproject.org/wiki/DocsProject/Schedule
Participants of the Fedora Documentation project have an updated
schedule here for release notes content and translation deadlines.
If you are brave and willing to deal with the unpredictability of
rawhide, your assistance in testing, reporting and fixing bugs as we
approach the November 14th devel freeze would be greatly appreciated.
Modular X requires FE5 Fixes
============================
The major change created by modular X is that XFree86-devel and
xorg-x11-devel are no longer provided in the buildroot. All packages in
both Core and Extras are now expected to have BuildRequires on the
individual libFOO-devel packages of the newly split modular X. In order
to ease into this, the current monolithic xorg-x11 package in rawhide
contains many virtual provides for libFOO-devel. Modular X itself will
hit rawhide *REAL SOON NOW*.
In addition to the lack of XFree86-devel and xorg-x11-devel,
/usr/X11R6/lib will disappear so packages that previously hardcoded this
path will need to be fixed. mharris has indicated that he is preparing
a webpage with further details about modular X and things that need to
be fixed.
Unfortunately FC5 rawhide will not be consistent and suitable for many
FE5 builds until the entire modular X tree is pushed. But when it does
happen, everyone's help will be needed to find problems in Core and
rebuild packages in Extras in order to rapidly prepare everything for test1.
Warren Togami
wtogami(a)redhat.com
5:19 p.m.
On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
If you are involved in the development of Fedora Core as a packager,
here is information that will be relevant to you.
FC5test1 devel freeze now November 14th
=======================================
Rawhide is undergoing a large amount of churn as we are preparing for
the switch from monolithic to modular X. Modular X is one of the larger
and more important changes of FC5, meaning we need extensive test
exposure. For this reason the test1 devel freeze has been postponed
until November 14th.
Warren,
While I know that the move to modular X is important, there's some other
nagging issues in rawhide that are going to drive the list mad if they
aren't addressed before test1 is released.
The most obvious of these (IMHO) is devices not appearing on desktop or
appearing to be mounted from Computer (et al) when they are indeed
mounted.
I also suspect that we're going to hear a lot from people with certain
Intel PCI chipsets who will suddenly find that they HDD/DVD performance
sucks in rawhide. I know that work is being done on this in the kernel,
but that at this stage nothing concrete (that I'm aware of) has been
done.
This last I don't expect to be fixed, but if the one above could be
addressed before test1 then this should really alleviate rampant "my
drive isn't appearing on the desktop" and "my drive isn't showing as
mounted in Computer" emails from eager testers who don't bother to read
the list (and subsequent rude "read the archive" emails too.) ;-]
Rodd
--
"It's a fine line between denial and faith.
It's much better on my side"
5:30 p.m.
On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
I also suspect that we're going to hear a lot from people with
certain
Intel PCI chipsets who will suddenly find that they HDD/DVD performance
sucks in rawhide. I know that work is being done on this in the kernel,
but that at this stage nothing concrete (that I'm aware of) has been
done.
Which bugzilla number is this ? My Intel chipset boxes run current
rawhide just fine, so I'm puzzled by this.
Dave
5:54 p.m.
On Thu, 2005-11-03 at 18:30 -0500, Dave Jones wrote:
On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
> I also suspect that we're going to hear a lot from people with certain
> Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> sucks in rawhide. I know that work is being done on this in the kernel,
> but that at this stage nothing concrete (that I'm aware of) has been
> done.
Which bugzilla number is this ? My Intel chipset boxes run current
rawhide just fine, so I'm puzzled by this.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363
I'm having to ide0=noprobe for mine, and my DVD performance sucks (in
capable of playing a DVD smoothly, or burning DVD/CDs disks at full
speed.
Or has something changed since this bug was posted that has improved the
situation and I no longer need ide0=noprobe?
Rodd
--
"It's a fine line between denial and faith.
It's much better on my side"
6:02 p.m.
On Fri, 2005-11-04 at 10:54 +1100, Rodd Clarkson wrote:
On Thu, 2005-11-03 at 18:30 -0500, Dave Jones wrote:
> On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
>
> > I also suspect that we're going to hear a lot from people with certain
> > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> > sucks in rawhide. I know that work is being done on this in the kernel,
> > but that at this stage nothing concrete (that I'm aware of) has been
> > done.
>
> Which bugzilla number is this ? My Intel chipset boxes run current
> rawhide just fine, so I'm puzzled by this.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363
I'm having to ide0=noprobe for mine, and my DVD performance sucks (in
capable of playing a DVD smoothly, or burning DVD/CDs disks at full
speed.
Or has something changed since this bug was posted that has improved the
situation and I no longer need ide0=noprobe?
Yes, same problem hit FC4 and is gone now...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169569
6:03 p.m.
On Fri, Nov 04, 2005 at 10:54:00AM +1100, Rodd Clarkson wrote:
On Thu, 2005-11-03 at 18:30 -0500, Dave Jones wrote:
> On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
>
> > I also suspect that we're going to hear a lot from people with certain
> > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> > sucks in rawhide. I know that work is being done on this in the kernel,
> > but that at this stage nothing concrete (that I'm aware of) has been
> > done.
>
> Which bugzilla number is this ? My Intel chipset boxes run current
> rawhide just fine, so I'm puzzled by this.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363
I'm having to ide0=noprobe for mine, and my DVD performance sucks (in
capable of playing a DVD smoothly, or burning DVD/CDs disks at full
speed.
Or has something changed since this bug was posted that has improved the
situation and I no longer need ide0=noprobe?
The PATA vs SATA bug got nuked about 2 weeks ago, so the noprobe thing
shouldn't be needed any more.
the last comment in that bz also suggests all is well now.
Dave
5:37 p.m.
On Fri, 2005-11-04 at 10:19 +1100, Rodd Clarkson wrote:
On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> If you are involved in the development of Fedora Core as a packager,
> here is information that will be relevant to you.
>
> FC5test1 devel freeze now November 14th
> =======================================
> Rawhide is undergoing a large amount of churn as we are preparing for
> the switch from monolithic to modular X. Modular X is one of the larger
> and more important changes of FC5, meaning we need extensive test
> exposure. For this reason the test1 devel freeze has been postponed
> until November 14th.
Warren,
While I know that the move to modular X is important, there's some other
nagging issues in rawhide that are going to drive the list mad if they
aren't addressed before test1 is released.
The most obvious of these (IMHO) is devices not appearing on desktop or
appearing to be mounted from Computer (et al) when they are indeed
mounted.
This problem is fixed in Hal cvs. We are working on a timetable for a
0.5.5 release, that will include these changes. Some of the
accompanying problems, like the duplicating cdrom icon, are bugs in
gnome-vfs. I have submitted patches but I have no idea when and if they
will be pulled into a new gnome-vfs release.
I also suspect that we're going to hear a lot from people with certain
Intel PCI chipsets who will suddenly find that they HDD/DVD performance
sucks in rawhide. I know that work is being done on this in the kernel,
but that at this stage nothing concrete (that I'm aware of) has been
done.
This last I don't expect to be fixed, but if the one above could be
addressed before test1 then this should really alleviate rampant "my
drive isn't appearing on the desktop" and "my drive isn't showing as
mounted in Computer" emails from eager testers who don't bother to read
the list (and subsequent rude "read the archive" emails too.) ;-]
Rodd
--
"It's a fine line between denial and faith.
It's much better on my side"
Jon
6:05 p.m.
Jon Nettleton wrote:
On Fri, 2005-11-04 at 10:19 +1100, Rodd Clarkson wrote:
> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
>
>> If you are involved in the development of Fedora Core as a packager,
>> here is information that will be relevant to you.
>>
>> FC5test1 devel freeze now November 14th
>> =======================================
>> Rawhide is undergoing a large amount of churn as we are preparing for
>> the switch from monolithic to modular X. Modular X is one of the larger
>> and more important changes of FC5, meaning we need extensive test
>> exposure. For this reason the test1 devel freeze has been postponed
>> until November 14th.
>>
> Warren,
>
> While I know that the move to modular X is important, there's some other
> nagging issues in rawhide that are going to drive the list mad if they
> aren't addressed before test1 is released.
>
> The most obvious of these (IMHO) is devices not appearing on desktop or
> appearing to be mounted from Computer (et al) when they are indeed
> mounted.
>
This problem is fixed in Hal cvs. We are working on a timetable for a
0.5.5 release, that will include these changes.
Will this also fix the problems with USB cameras (all 457 different
types of USB camera, afaict) ?
John
6:10 p.m.
On Thu, 2005-11-03 at 19:05 -0500, John Ellson wrote:
Jon Nettleton wrote:
> On Fri, 2005-11-04 at 10:19 +1100, Rodd Clarkson wrote:
>
>> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
>>
>>> If you are involved in the development of Fedora Core as a packager,
>>> here is information that will be relevant to you.
>>>
>>> FC5test1 devel freeze now November 14th
>>> =======================================
>>> Rawhide is undergoing a large amount of churn as we are preparing for
>>> the switch from monolithic to modular X. Modular X is one of the larger
>>> and more important changes of FC5, meaning we need extensive test
>>> exposure. For this reason the test1 devel freeze has been postponed
>>> until November 14th.
>>>
>> Warren,
>>
>> While I know that the move to modular X is important, there's some other
>> nagging issues in rawhide that are going to drive the list mad if they
>> aren't addressed before test1 is released.
>>
>> The most obvious of these (IMHO) is devices not appearing on desktop or
>> appearing to be mounted from Computer (et al) when they are indeed
>> mounted.
>>
>
> This problem is fixed in Hal cvs. We are working on a timetable for a
> 0.5.5 release, that will include these changes.
Will this also fix the problems with USB cameras (all 457 different
types of USB camera, afaict) ?
John
These fixes are all limited to removable storage. I was unaware that
there were problems with USB cameras. Do you have a bugzilla I can
reference?
Jon
8:47 p.m.
Jon Nettleton wrote:
>>> The most obvious of these (IMHO) is devices not appearing on desktop or
>>> appearing to be mounted from Computer (et al) when they are indeed
>>> mounted.
>>>
>>>
>> This problem is fixed in Hal cvs. We are working on a timetable for a
>> 0.5.5 release, that will include these changes.
>>
> Will this also fix the problems with USB cameras (all 457 different
> types of USB camera, afaict) ?
>
> John
>
>
These fixes are all limited to removable storage. I was unaware that
there were problems with USB cameras. Do you have a bugzilla I can
reference?
Jon
Yes: #170690, #168933, #150985, #165914
John
7:51 a.m.
On Thu, 2005-11-03 at 21:47 -0500, John Ellson wrote:
Jon Nettleton wrote:
>
>>>> The most obvious of these (IMHO) is devices not appearing on desktop or
>>>> appearing to be mounted from Computer (et al) when they are indeed
>>>> mounted.
>>>>
>>>>
>>> This problem is fixed in Hal cvs. We are working on a timetable for a
>>> 0.5.5 release, that will include these changes.
>>>
>> Will this also fix the problems with USB cameras (all 457 different
>> types of USB camera, afaict) ?
>>
>> John
>>
>>
>
> These fixes are all limited to removable storage. I was unaware that
> there were problems with USB cameras. Do you have a bugzilla I can
> reference?
>
> Jon
>
>
Yes: #170690, #168933, #150985, #165914
John
If the camera is seen as a removable usb storage device, which it sounds
like these are, then yes it will. The quick way to tell if it will fix
your problem is look in the /media directory. If you camera is being
properly mounted in there and the only problem is it is not showing up
on the nautilus desktop or in drive applet, then these problems are
mostly resolved.
Jon
3:17 p.m.
Jon Nettleton wrote:
On Thu, 2005-11-03 at 21:47 -0500, John Ellson wrote:
> Jon Nettleton wrote:
>
>>>>> The most obvious of these (IMHO) is devices not appearing on desktop
or
>>>>> appearing to be mounted from Computer (et al) when they are indeed
>>>>> mounted.
>>>>>
>>>>>
>>>>>
>>>> This problem is fixed in Hal cvs. We are working on a timetable for a
>>>> 0.5.5 release, that will include these changes.
>>>>
>>>>
>>> Will this also fix the problems with USB cameras (all 457 different
>>> types of USB camera, afaict) ?
>>>
>>> John
>>>
>>>
>>>
>> These fixes are all limited to removable storage. I was unaware that
>> there were problems with USB cameras. Do you have a bugzilla I can
>> reference?
>>
>> Jon
>>
>>
>>
> Yes: #170690, #168933, #150985, #165914
>
>
> John
>
>
If the camera is seen as a removable usb storage device, which it sounds
like these are, then yes it will. The quick way to tell if it will fix
your problem is look in the /media directory. If you camera is being
properly mounted in there and the only problem is it is not showing up
on the nautilus desktop or in drive applet, then these problems are
mostly resolved.
Jon
The camera is not currently showing up in /media, but running gphoto2 as
root finds it OK.
I currently have hal-0.5.4. I'll try again when hal-0.5.5 shows up.
John
8:13 p.m.
On Fri, 04 Nov 2005 08:51:56 -0500, Jon Nettleton <jon.nettleton(a)gmail.com> wrote:
> > These fixes are all limited to removable storage. I was
unaware that
> > there were problems with USB cameras. Do you have a bugzilla I can
> > reference?
> Yes: #170690, #168933, #150985, #165914
If the camera is seen as a removable usb storage device, which it
sounds
like these are, then yes it will. The quick way to tell if it will fix
your problem is look in the /media directory. [...]
There is no need be so indirect. There's an lsusb dump in one of the
innumeorus bugs which John filed. You do not even have to parse it
yourself, David Zeuten pronounced the camera storage-incompatible
in that bug (correctly).
I am not completely convinced that this issue is worth fixing, because of
security implications. However, it would be nice if someone came up with a configuration
for pam and udev which would make console user the owner of
/proc/bus/usb/*/*
-- Pete
8:45 p.m.
Pete Zaitcev wrote:
On Fri, 04 Nov 2005 08:51:56 -0500, Jon Nettleton
<jon.nettleton(a)gmail.com> wrote:
>>> These fixes are all limited to removable storage. I was unaware that
>>> there were problems with USB cameras. Do you have a bugzilla I can
>>> reference?
>>>
>> Yes: #170690, #168933, #150985, #165914
>>
> If the camera is seen as a removable usb storage device, which it sounds
> like these are, then yes it will. The quick way to tell if it will fix
> your problem is look in the /media directory. [...]
>
There is no need be so indirect. There's an lsusb dump in one of the
innumeorus bugs which John filed. You do not even have to parse it
yourself, David Zeuten pronounced the camera storage-incompatible
in that bug (correctly).
I am not completely convinced that this issue is worth fixing, because of
security implications. However, it would be nice if someone came up with a configuration
for pam and udev which would make console user the owner of
/proc/bus/usb/*/*
-- Pete
Be careful with my multiple bug reports. I've been posting reports for
over a year now to try to get some attention on this problem. The
earliest reports
were for a Canon PowerShot G3, but the most recent are for a Canon
PowerShot Pro1.
I don't know that the protocols are the same. I no longer have the G3,
so all I can
tell you is that the Pro1 doesn't work today (except as root).
What security implications? Are you suggesting it would be better if
photographers
had to run gphoto2 as root to get their pictures?
Please, lets make this system useful for something other than
recompiling kernels!
How can I get my wife to use Linux if she can't process her photos!!!
It would be OK if the system administrator had to authorize a new camera
on the system.
But don't make me read any more out-of-date, inaccurate, howtos on
gphoto/hal/udev/hotplug/kitchensink...
I would like to help fix this if someone would provide some direction,
but right now
this USB stuff strikes me as a first class monster.
John
2:44 a.m.
On Thu, 2005-11-03 at 18:37 -0500, Jon Nettleton wrote:
> The most obvious of these (IMHO) is devices not appearing on
desktop or
> appearing to be mounted from Computer (et al) when they are indeed
> mounted.
This problem is fixed in Hal cvs. We are working on a timetable for a
0.5.5 release, that will include these changes. Some of the
accompanying problems, like the duplicating cdrom icon, are bugs in
gnome-vfs. I have submitted patches but I have no idea when and if they
will be pulled into a new gnome-vfs release.
I commited the patch in
http://bugzilla.gnome.org/show_bug.cgi?id=319689 , but its a bit strange
that the second patch is identical to the first. Did you attach the
wrong file?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alla(a)lysator.liu.se
He's a suicidal flyboy dog-catcher living undercover at Ringling Bros. Circus.
She's a vivacious Buddhist bounty hunter with her own daytime radio talk show.
They fight crime!
6:39 a.m.
On Fri, 2005-11-04 at 09:44 +0100, Alexander Larsson wrote:
On Thu, 2005-11-03 at 18:37 -0500, Jon Nettleton wrote:
> > The most obvious of these (IMHO) is devices not appearing on desktop or
> > appearing to be mounted from Computer (et al) when they are indeed
> > mounted.
>
> This problem is fixed in Hal cvs. We are working on a timetable for a
> 0.5.5 release, that will include these changes. Some of the
> accompanying problems, like the duplicating cdrom icon, are bugs in
> gnome-vfs. I have submitted patches but I have no idea when and if they
> will be pulled into a new gnome-vfs release.
I commited the patch in
http://bugzilla.gnome.org/show_bug.cgi?id=319689 , but its a bit strange
that the second patch is identical to the first. Did you attach the
wrong file?
Thanks. That second patch is the wrong version. I was bouncing from my
desktop to laptop and forgot to sync up my patches directory. I have
uploaded the proper version of the patch to bugzilla. If you would like
I can make a smaller one against what you have already committed.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alla(a)lysator.liu.se
He's a suicidal flyboy dog-catcher living undercover at Ringling Bros. Circus.
She's a vivacious Buddhist bounty hunter with her own daytime radio talk show.
They fight crime!
Jon
6:10 p.m.
Rodd Clarkson wrote:
On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
>If you are involved in the development of Fedora Core as a packager,
>here is information that will be relevant to you.
>
>FC5test1 devel freeze now November 14th
>=======================================
>Rawhide is undergoing a large amount of churn as we are preparing for
>the switch from monolithic to modular X. Modular X is one of the larger
>and more important changes of FC5, meaning we need extensive test
>exposure. For this reason the test1 devel freeze has been postponed
>until November 14th.
Warren,
While I know that the move to modular X is important, there's some other
nagging issues in rawhide that are going to drive the list mad if they
aren't addressed before test1 is released.
The most obvious of these (IMHO) is devices not appearing on desktop or
appearing to be mounted from Computer (et al) when they are indeed
mounted.
I also suspect that we're going to hear a lot from people with certain
Intel PCI chipsets who will suddenly find that they HDD/DVD performance
sucks in rawhide. I know that work is being done on this in the kernel,
but that at this stage nothing concrete (that I'm aware of) has been
done.
This last I don't expect to be fixed, but if the one above could be
addressed before test1 then this should really alleviate rampant "my
drive isn't appearing on the desktop" and "my drive isn't showing as
mounted in Computer" emails from eager testers who don't bother to read
the list (and subsequent rude "read the archive" emails too.) ;-]
Make sure these issues get filed in bugzilla as soon as they're
discovered, in order to maximize the chances of them getting
fixed sooner rather than later.
If everyone does their part in reporting bugs, it greatly helps
to get the distro in better shape earlier.
Thanks in advance, and thanks for testing!
TTYL
9:40 p.m.
On Thu, 2005-11-03 at 19:10 -0500, Mike A. Harris wrote:
Rodd Clarkson wrote:
> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
>
>>If you are involved in the development of Fedora Core as a packager,
>>here is information that will be relevant to you.
>>
>>FC5test1 devel freeze now November 14th
>>=======================================
>>Rawhide is undergoing a large amount of churn as we are preparing for
>>the switch from monolithic to modular X. Modular X is one of the larger
>>and more important changes of FC5, meaning we need extensive test
>>exposure. For this reason the test1 devel freeze has been postponed
>>until November 14th.
>
>
> Warren,
>
> While I know that the move to modular X is important, there's some other
> nagging issues in rawhide that are going to drive the list mad if they
> aren't addressed before test1 is released.
>
> The most obvious of these (IMHO) is devices not appearing on desktop or
> appearing to be mounted from Computer (et al) when they are indeed
> mounted.
>
> I also suspect that we're going to hear a lot from people with certain
> Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> sucks in rawhide. I know that work is being done on this in the kernel,
> but that at this stage nothing concrete (that I'm aware of) has been
> done.
>
> This last I don't expect to be fixed, but if the one above could be
> addressed before test1 then this should really alleviate rampant "my
> drive isn't appearing on the desktop" and "my drive isn't showing
as
> mounted in Computer" emails from eager testers who don't bother to read
> the list (and subsequent rude "read the archive" emails too.) ;-]
Make sure these issues get filed in bugzilla as soon as they're
discovered, in order to maximize the chances of them getting
fixed sooner rather than later.
Both have already been bugzilla'd for some time now.
If everyone does their part in reporting bugs, it greatly helps
to get the distro in better shape earlier.
That's what I do with fedora, report bugs. I don't code, but I can test
(and if people help me a little I can get the right info to help track
down bugs too ;-])
Thanks in advance, and thanks for testing!
You're welcome
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
3:30 p.m.
Hi
That's what I do with fedora, report bugs. I don't code, but
I can test
(and if people help me a little I can get the right info to help track
down bugs too ;-])
Reporting bugs is a very useful thing to do. Might also want to look at
bug triaging
http://fedoraproject.org/wiki/BugZappers
regards
Rahul
9:02 p.m.
On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
If you are involved in the development of Fedora Core as a packager,
here is information that will be relevant to you.
Modular X requires FE5 Fixes
============================
The major change created by modular X is that XFree86-devel and
xorg-x11-devel are no longer provided in the buildroot. All packages in
both Core and Extras are now expected to have BuildRequires on the
individual libFOO-devel packages of the newly split modular X. In order
to ease into this, the current monolithic xorg-x11 package in rawhide
contains many virtual provides for libFOO-devel. Modular X itself will
hit rawhide *REAL SOON NOW*.
Will we see corresponding "Provides: libFOO-devel = x.y.z" being added
to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward
compatibility?
Ralf
10:24 a.m.
On Fri, 2005-11-04 at 04:02 +0100, Ralf Corsepius wrote:
On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> If you are involved in the development of Fedora Core as a packager,
> here is information that will be relevant to you.
> Modular X requires FE5 Fixes
> ============================
> The major change created by modular X is that XFree86-devel and
> xorg-x11-devel are no longer provided in the buildroot. All packages in
> both Core and Extras are now expected to have BuildRequires on the
> individual libFOO-devel packages of the newly split modular X. In order
> to ease into this, the current monolithic xorg-x11 package in rawhide
> contains many virtual provides for libFOO-devel. Modular X itself will
> hit rawhide *REAL SOON NOW*.
Will we see corresponding "Provides: libFOO-devel = x.y.z" being added
to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward
compatibility?
Now that would be so _nice_. Mike, pretty please?
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)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
5:47 p.m.
Ralf Corsepius wrote:
On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
>If you are involved in the development of Fedora Core as a packager,
>here is information that will be relevant to you.
>Modular X requires FE5 Fixes
>============================
>The major change created by modular X is that XFree86-devel and
>xorg-x11-devel are no longer provided in the buildroot. All packages in
>both Core and Extras are now expected to have BuildRequires on the
>individual libFOO-devel packages of the newly split modular X. In order
>to ease into this, the current monolithic xorg-x11 package in rawhide
>contains many virtual provides for libFOO-devel. Modular X itself will
>hit rawhide *REAL SOON NOW*.
Will we see corresponding "Provides: libFOO-devel = x.y.z" being added
to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward
compatibility?
That's not a bad idea. If somebody files separate bug reports against
FC3 and FC4, I'll try to make sure the next Fedora updates have these
virtual provides present. That will make things even easier for
3rd party repos to share spec files between various distro releases.
Not sure when we'll make the next FC Xorg updates though, we're pretty
tied down right now. ;) But there will be updates at some point.
Thanks for the suggestion.
4:20 p.m.
New subject: Requirements with modular X
Warren Togami writes:
In addition to the lack of XFree86-devel and xorg-x11-devel,
/usr/X11R6/lib will disappear so packages that previously hardcoded this
path will need to be fixed.
A package needs the truetype fonts luxi*.ttf. Because of the package
name change from XFree86-truetype-fonts to fonts-xorg-truetype
previously, I made the requirement be
/usr/X11R6/lib/X11/fonts/TTF/luximbi.ttf etc. I also have a similar
dependency on the xhost program, solved in the same way.
There won't be any way to have a requirement on these fonts for all
three levels: XFree86, monolithic xorg, modular xorg, will there?
(The XFree86 based system I need to support is RHEL3, so this is maybe
"semi off topic".)
10:33 a.m.
New subject: Requirements with modular X
Göran Uddeborg wrote:
Warren Togami writes:
>In addition to the lack of XFree86-devel and xorg-x11-devel,
>/usr/X11R6/lib will disappear so packages that previously hardcoded this
>path will need to be fixed.
A package needs the truetype fonts luxi*.ttf. Because of the package
name change from XFree86-truetype-fonts to fonts-xorg-truetype
previously, I made the requirement be
/usr/X11R6/lib/X11/fonts/TTF/luximbi.ttf etc. I also have a similar
dependency on the xhost program, solved in the same way.
There won't be any way to have a requirement on these fonts for all
three levels: XFree86, monolithic xorg, modular xorg, will there?
(The XFree86 based system I need to support is RHEL3, so this is maybe
"semi off topic".)
Hmm. This is an interesting problem. Any solution that I can
think of to this, has both advantages and disadvantages, however
I think the following solution has the least disadvantages, and
is simple to implement.
I can add a new virtual provide to modular X, and monolithic X,
which provides the luxi fonts. Of course the disadvantage of this,
is that the virtual provide wont pre-exist in any currently
released OS products, but it can be added in future erratum.
Provides: luxi-truetype-fonts
Provides: luxi-Type1-fonts
Does this sound reasonable?
The other alternative, is to conditionalize the spec file with
build_fc1 build_fc2 build_fc3 build_fc4 build_fc5 macros, but
that's kindof sucktacular.
I'm open to suggestions.
3:28 p.m.
New subject: Requirements with modular X
Mike A. Harris writes:
Provides: luxi-truetype-fonts
Provides: luxi-Type1-fonts
Does this sound reasonable?
It does to me. Since there is nothing that will work with current
packages in old systems, something that will work after some erratum
is released would be second best.
The other alternative, is to conditionalize the spec file with
build_fc1 build_fc2 build_fc3 build_fc4 build_fc5 macros,
If possible, I would avoid that.
6744
days inactive
6748
days old
24 comments
13 participants
participants (13)
-
Alexander Larsson -
Dave Jones -
Gawain Lynch -
Göran Uddeborg -
John Ellson -
Jon Nettleton -
Mike A. Harris -
Nils Philippsen -
Pete Zaitcev -
Rahul Sundaram -
Ralf Corsepius -
Rodd Clarkson -
Warren Togami