rawhide report: 20040527 changes
by Build System
Updated Packages:
cups-1.1.20-10
--------------
* Wed May 26 2004 Tim Waugh <twaugh(a)redhat.com> 1:1.1.20-10
- Finish fix for cupsenable/cupsdisable (bug #102490).
- Fix MaxLogSize setting (bug #123003).
device-mapper-1.00.17-2.0
-------------------------
* Wed May 26 2004 Alasdair Kergon <agk(a)redhat.com> - 1.00.17-2
- Fix is_selinux_enabled() test
* Mon Apr 19 2004 Alasdair Kergon <agk(a)redhat.com> - 1.00.17-1
- Fix non-root build with current version of 'install'.
- Incorporate last two selinux patches into tarball.
hfsutils-3.2.6-3
----------------
* Mon Apr 19 2004 David Woodhouse <dwmw2(a)redhat.com> 3.2.6-3
- BuildRequires tk-devel
iproute-2.4.7-16
----------------
* Wed May 26 2004 Phil Knirsch <pknirsch(a)redhat.com> 2.4.7-16
- Took tons of manpages from debian, much more complete (#123952).
lvm2-2.00.15-4
--------------
* Wed May 26 2004 Alasdair Kergon <agk(a)redhat.com> - 2.00.15-4
- clone %description from LVM rpm
* Wed May 26 2004 Alasdair Kergon <agk(a)redhat.com> - 2.00.15-3
- vgscan shouldn't return error status when no VGs present
rpmdb-fedora-2-0.20040527
-------------------------
subversion-1.0.2-2.1
--------------------
* Sat May 15 2004 Joe Orton <jorton(a)redhat.com> 1.0.2-2.1
- add security fix for CVE CAN-2004-0397 (Ben Reser)
* Tue May 04 2004 Joe Orton <jorton(a)redhat.com> 1.0.2-2
- add perl MODULE_COMPAT requirement for -perl subpackage
- move perl man pages into -perl subpackage
- clean up -perl installation and dependencies (Ville Skyttä, #123045)
* Mon Apr 19 2004 Joe Orton <jorton(a)redhat.com> 1.0.2-1
- update to 1.0.2
vnc-4.0-1.beta5.2
-----------------
* Wed May 26 2004 Tim Waugh <twaugh(a)redhat.com> 4.0-1.beta5.2
- Switch to xorg-x11 (bug #119530).
19 years, 11 months
Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in Fedora Core 3
by Bryan Smith
[ This is a tangent based on this post:
http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00800.html
from the original thread that started with this post:
http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00782.html
]
Steven Pritchard wrote:
> Although, again, I don't think it makes a bit of sense to have an
> app like Scribus in Core. It's definitely Extras material in my mind.
> Of course, at this point I'm thinking OpenOffice, Gimp, and various
> other things are looking like nice targets for Extras. 4 CDs for
> Core? :-)
Steven brings up a larger issue. With Fedora going to the "distributed"
model, at what point do we start to try (if at all?) to "reduce" the
size Fedore "Core" (FC)?
I mean, is there a reason we need to maintain a 3+ CD set for FC, just
as to match the "legacy" design of old Red Hat Linux (RHL)?
I personally would like to see "Core" reduced to a _single_ binary CD.
Maybe call it Fedora "miniCore" (FmC)?**
Or maybe Fedora Quark (FQ)? I kinda like that better.
But that is a larger issue for the steering committee.
BTW, I hope I'm not the first one to suggest this?
>From Steve's post, I assume not.
-- Bryan J. Smith, "Lurker"
**NOTE: This is just a suggestion. I'm not one to name things.
In fact, I was first going to suggest Fedora "microCore" instead of
Fedora "miniCore" but the common use of "u" as the character for "Mu"
for "micro" produces a rather "intersting" acronym -- i.e., "FuC".
;-ppp
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
xdaliclock rpm for fedora core 2 ?
by Gabriel L. Somlo
Wanted to build xdaliclock from src.rpm myself, so I ripped PLD's
xdaliclock-2.20-1.src.rpm
(http://rpmfind.net/linux/RPM/PLD/dists/ra/updates/general/i386/xdaliclock...)
and made it build on my brand-spanking-new Fedora Core 2 install !
The modified spec file is attached (along with pld's two patches) for
your rpm-building convenience.
Please let me know in case this is redundant and/or if there's a
better place to send this kind of thing. (is there a FC2 'extras'
repository ?)
Thanks,
Gabriel
19 years, 11 months
debugging xorg-x11
by Chuck Anderson
I have a FC2 system whose X11 has locked up after sitting on a
screensaver overnight. I can still get into the system via ssh, but I
cannot vt switch away from the locked up X11. The X process is taking
up all the CPU:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 23040 97.7 5.2 67488 20248 ? R May 22 1-16:02:50 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
strace shows it in a tight loop:
select(1024, [8], NULL, NULL, {0, 0}) = ? ERESTARTNOHAND (To be restarted)
select(1024, [8], NULL, NULL, {0, 0}) = ? ERESTARTNOHAND (To be restarted)
select(1024, [8], NULL, NULL, {0, 0}) = ? ERESTARTNOHAND (To be restarted)
Xorg.0.log shows this repeating error:
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
...
How can I go about debugging this so I can make a meaningful bug
report? What debuginfo packages and gdb version do I need?
xorg-x11-6.7.0-2 is using radeon driver for this card:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Radeon 7000/Radeon VE
Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 161
Memory at d0000000 (32-bit, prefetchable)
I/O ports at d000 [size=256]
Memory at dd000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
kernel is 2.6.5-1.358smp. Chipset:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
Flags: bus master, medium devsel, latency 0
Memory at d8000000 (32-bit, prefetchable)
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
Expansion ROM at 0000d000 [disabled] [size=4K]
Capabilities: [80] Power Management version 2
CPUs:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 799.919
cache size : 256 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 pse36 mmx fxsr sse
bogomips : 1572.86
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 799.919
cache size : 256 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 pse36 mmx fxsr sse
bogomips : 1597.44
Thanks.
19 years, 11 months
rpm package renames
by Stuart Children
Hi
Suppose I have a package foo, which I need to rename to bar (to better fit
package naming guidelines, or for trademark reasons say). What exact magic
do I need in my bar spec file to ensure upgrades go smoothly? "Obsoletes:
foo" obviously. I'm guessing probably also restricting it to <= the last
version released as foo to be paranoid - is that definitely
necessary/suggested?
I've seen some notes saying that Obsoletes should be paired with Provides.
In what situations should one do that? If I'm certain foo is not
explicitely Required by any other packages, can I safely skip it?
Whilst playing around I noticed that if the versions of foo and bar are
the same (which in this case they won't be, but consider bar being a whole
new project that is designed to replace foo) then foo is not removed
when upgrading to bar. Which confused the hell out of me for a while
last night (that and the difference installing vs upgrading, but I can
understand that). :)
I can't find any definite guidelines or indeed explainations of exactly
how rpm treats Obsoletes. This is very frustrating, and lack of
documentation is surely a reason why packaging is sometimes considered a
black art when it should be quite accessible to developers.
Anyway, if people can come up with some guidelines here then perhaps they
could be added to the following pages:
http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html
http://www.fedora.us/wiki/PackagingHints
PS: Before I forget, is there an easy way to find out who is supposed to
be maintaining a particular package in the fedora.us repository?
TIA
--
Stuart
19 years, 11 months
rawhide packages behide updates/testing??
by Brian Millett
There are several packages in rawhide that are behide the packages in
updates/testing.
updates rawhide
kudzu-1.1.68-1 kudzu-1.1.67-1
subversion-1.0.4-1 subversion-1.0.3-1
I'm confussed. Should I, once I go down the rawhide path, ignore updates?
Shouldn't rawhide be the "bleeding-edge"?
Thanks.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpmATec-groupDOTcom Greg Glenn
19 years, 11 months
Prevention and Recovery of XP Dual Boot Problems
by Jack Aboutboul
This is the whole document for those who didnt get it.
<---BEGIN--->
Dual Booting Issues With Fedora Core 2 and Windows: Prevention & Recovery
NOTICE: Please read this document in its entirety.
This guide was inspired by the solution developed by Radu Cornea and
Alexandre Oliva in this thread:
http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html .
This guide aims to integrate the original solution with the refinements
evolved in that thread. This guide offers an explanation of why the
refinements are beneficial and some workarounds to problems that may prevent
the uninitiated from using the solution. It also provides a means of
preventing the problem entirely.
Primer:
There is a bug in Fedora Core 2 that causes the hard disk geometry as
reported in the partition table to be altered during installation. This
change may cause Windows boot failure. Although this bug is severe, it is
recoverable and no data should be lost. It is important not to panic if and
when this happens so you do not cause further problems or cause actual loss
of data in the process of recovering from the error.
Prevention:
This bug can be avoided entirely by using some preventative steps while
installing Fedora Core 2. Thanks go out to Cero (cero(a)coolnetworx.net) for
discovery and testing of this solution.
To avoid the hard disk geometry to be altered you may enter it manually
during installation by using the hdN=<drive geometry> parameter (where N is
the letter representing the drive with the MBR you will use). To discover
the current geometry before installing Fedora Core 2 you should use a
utility that can read the drive geometry as reported in the partition table.
It is important to understand that some tools may not be reporting the
actual data from this location, but, rather, some derived value, so your
surest way is to use the fdisk utility. You can get this information by
following these steps.
Note: This example will assume you are looking at /dev/hda, which is the
master on the primary IDE interface. If your MBR is located on another
device you should use its name (eg: /dev/hde )
Download and burn the Fedora Core 2 Rescue CD.
Boot from the Rescue CD (there is no need to start networking or mount
drives)
Issue the command: fdisk -l /dev/hda to print the current partition table
to screen in non-interactive mode.
Write down the drive geometry as reported at the beginning of the output
from fdisk. This is reported as number of Cylinders, Heads, and Sectors
(hence the name CHS).
You can now reboot the computer by simultaneously holding down the keys
Ctrl-Alt-Delete.
You can now boot the Fedora Core 2 installation CD. At the first menu prompt
you should now choose to run the installer with the known geometry.
Example: linux hda=14593,255,63
The installer should now run normally and not alter your partition table
geometry entry. If, for any reason, this geometry should be changed
regardless of this preventative step, please use the recovery steps to
correct the geometry of the drive as reported by the partition table.
Recovery:
You have installed Fedora Core 2 and find that you cannot boot Windows.
Typically the boot process will terminate with the words
Rootnoverify(hd0,0)
Chainloader +1
These are the boot parameters from your Grub configuration. The parameters
are likely to be correct, but Windows fails to boot because Fedora Core 2
altered the hard disk geometry as reported by the drives partition table.
IMPORTANT: Do not panic and do not begin using multiple tools in an attempt
to correct this error. Automated tools can be very dangerous. The actual
changes that need to be made are minor and benign. By running 3rd party
applications to recover a bootable Windows installation may cause you to
lose your data. You have been warned.
For those who are technically inclined I include here a brief explanation
of what is going on. The drive has not been damaged and your partition
table is fine. The problem is that Windows demands a "sane" CHS table.
This table has been altered by Fedora Cores installer and Windows hangs.
Luckily, the actual table, in LBA format, is not corrupted. For those
seeing a strange partition table, take note that you are probably looking at
the table in CHS values and these values are derived from the geometry. The
GNU/Linux operating system does not use these values and operates purely
with LBA values. Windows should not be using CHS either, but for some
reason it at least checks this geometry and can be prevented from booting by
them being bad. Changing the drive geometry changes the CHS partition table
because this is a virtualization of the true state of affairs on the drive
which are best described as being mystical. Think of CHS geometry as a
compass. If you change the geometry you have recalibrated where the
needles reference point is and you are no longer looking at true north.
The solution to this problem is very simple, but it may confuse people
because most people will question why they are seeing strange values
reported from their partition table in CHS format. If you do not trust this
solution or your ability to follow these steps then you should stop and seek
hard disk recovery consulting services. The Fedora Project is in no way
liable for any data loss and this guide is offered without guarantees. You
are taking responsibility for what happens. Now, let us go through the
solution.
Because only the drive geometry is altered there is no need for manual
intervention in the form of discovering and entry of partition information.
The information in your partition table is correct. However, you need to
alter the geometry entry and normally this would require you to re-enter the
partition table by hand using a tool like fdisk. This is where the
application sfdisk comes to the rescue. Sfdisk can be very powerful in
non-interactive mode, it can output information that can be used as input
elsewhere, and it can accept data as input at run-time. This makes sfdisk
ideal for this solution because you can ask it to read the partition table
and deliver the result in a way that itself can write back when you tell it
to change your drive geometry. This makes the process fast and less prone
to human error as very few values need to be supplied. The solution can be
summed up in a single line with two commands:
sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda
So that the reader may better understand what is going on here, lets go
through what each section does and what the parameters mean.
sfdisk -d /dev/hda
This part runs sfdisk non-interactively and dumps the partition table in a
format that sfdisk can also use for input (as we are doing). Try this
command by itself to see your partition table as it is very safe. You will
want to check to check for warnings in the output. Warnings pose a problem
because they interfere with the use of this data as input. Output containing
a warning may look like the example below:
$ sfdisk -d /dev/hda
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
# partition table of /dev/hda
unit: sectors
/dev/hda1 : start= 63, size= 16771797, Id= 7, bootable
/dev/hda2 : start= 16771860, size=217632555, Id= f
/dev/hda3 : start= 0, size= 0, Id= 0
/dev/hda4 : start= 0, size= 0, Id= 0
/dev/hda5 : start= 16771923, size=104856192, Id= 7
/dev/hda6 : start=121628178, size=112776237, Id= 7
For reasons unknown, using the option -- quiet does not suppress all
warnings so it becomes the task of the user to discover a way to still use
the output as input. The simplest way is to write the output to a plain
text file, editing out the warning in that text file, and using the edited
text file as the input, thus:
sfdisk -d /dev/hda > MyPartitionTable.txt
editing MyPartitionTable.txt to remove the warnings, saving the edited
text, and
cat MyPartitionTable.txt | sfdisk --no-reread -H255 /dev/hda
The output from "sfdisk -d /dev/hda" should begin like this (this is the
edited version of the example given before):
# partition table of /dev/hda
unit: sectors
/dev/hda1 : start= 63, size= 16771797, Id= 7, bootable
/dev/hda2 : start= 16771860, size=217632555, Id= f
/dev/hda3 : start= 0, size= 0, Id= 0
/dev/hda4 : start= 0, size= 0, Id= 0
/dev/hda5 : start= 16771923, size=104856192, Id= 7
/dev/hda6 : start=121628178, size=112776237, Id= 7
Note that "cat MyPartitionTable.txt" takes the place of "sfdisk -d
/dev/hda" as these are now equivalent. In this case the warning portion has
been stripped, preserving the needed data used by sfdisk in step two of the
command.
sfdisk --no-reread -H255 /dev/hda
This portion of the two-part command performs the actual change to your
hard disk. This main operation is in -H255. This tells sfdisk to write a
head count of 255 into the drive geometry. This command executed by itself
would ask for user input of the partition table (just like fdisk). However,
by piping the table we just read in the first command, this is avoided and
work is saved and we know the data is correct (or, at least, unchanged).
This is why sfdisk is used.
The --no-reread option allows the command to run even when the disk has a
mounted partition. Some users may find they need to further force the
operation to complete. This is done by using --force (sfdisk --no-reread
--force -H255 /dev/hda).
In this example we are only changing the number of heads in the geometry.
If you know the correct number of cylinders before the Fedora Core
installation changed these values you may also write back this number. An
example with 14,593 cylinders is provided below.
sfdisk -d /dev/hda | sfdisk --no-reread -H255 -C14593 /dev/hda
The number of reported sectors (S) should not have changed and remained as
63.
This is the part most likely to be met with the question "if I change the
number of heads, must I not also change the the number of cylinders?" The
answer to this question is "no." When the geometry was changed the number
of heads changed from 255 to 16 and the number of cylinders was increased to
compensate. As long as the values are large everything should be ok. Only
the pedantic need worry about changing the number of cylinders manually. If
you do not know the value from before you are best off not supplying this
number.
By using this method there is no need, and indeed you should not, run a
program that wipes the MBR (like fdisk /mbr). Doing so will cause you to
lose the Grub pointer installed in the MBR and you will have to use the
Recovery CD to regain access to your Fedora Core installation.
Updating Grub after installation seems to have no effect on the drive
geometry as the problem seems strictly limited to the Fedora Core installer.
Good luck and join us on the IRC at #fedora on irc.freenode.net for any
questions you have or contributions to the community you wish to make.
19 years, 11 months