I can't find the policy regarding library (sub-)packages. I am packaging a
digital camera program for KDE called DigiKam (#1404). This package can use
a plugins package for more features: digikamplugins (#1406). Thus,
digikamplugins depends on libdigikam.so. But then, an image viewer for KDE
called ShowImg (#1410) can also use digikam's plugins. In the end, we have
an image viewer depending on a digital camera manager. This could be fixed
by splitting libdigikam out of the main package, but it looks like it is
rarely done in the Fedora distribution. Is there a policy regarding this
kind of situation (I'm sure it is neither the only nor the fist time this
happens) ? Is there a general policy as regards to sub-packages, and to
library packages ?
http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info
"As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours ; and
this we should do freely and generously." -- Benjamin Franklin
My update packages for k3b are in need of further reviews according
to the fedora.us package submission and QA policies.
k3b 0.11.6 (one review)
k3b i18n 0.11
Alternatively, if someone likes to take over the packages (I'm not the
initial packager and have prepared the 0.9.x and 0.10.x updates only),
that would be appreciated, too, as I would add the required review.
My motivation to review and approve new packages has reached an all-time
low, when I see that the very few packages which I maintain or which I
have brought into shape during QA, don't seem to get published.
Notice that most package updates are considerably easier to review than
new package requests, since an update can be compared with the previous
release. Verification and confirmation of the included tarball checksum
is the most important step.
recently I installed Fedore Core 1 on a PC with a FastTrack 133 "Lite"
<14:33:12> macmewes@linux:~ $ df
Filesystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/hdg2 79048292 6264524 68768324 9% /
/dev/hdg1 101086 8337 87530 9% /boot
/dev/hdh1 77348004 375092 73043820 1% /home
none 775416 0 775416 0% /dev/shm
This is a parallel installation with Windows XP which is on the first
two harddisks which I would see as hda and hdb if Fedora Kernels came
with NTFS-Support for mounting them into my system for reading only.
I do not want to start a chit-chat about why this feature is not in
Fedore-Kernels, but what I wonder about is if Windows XP resides on
hda and hdb why Fedora (as well as SuSE, RedHat, Knoppix, Debian ...)
is starting to acutally see the harddisks not with hda but hde?
A "demsg"-extract for you ...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
SiI3112 Serial ATA: IDE controller at PCI slot 00:08.0
SiI3112 Serial ATA: chipset revision 2
SiI3112 Serial ATA: not 100% native mode: will probe irqs later
ide0: MMIO-DMA , BIOS settings: hda:pio, hdb:pio
ide1: MMIO-DMA , BIOS settings: hdc:pio, hdd:pio
PDC20276: IDE controller at PCI slot 00:0f.0
PDC20276: chipset revision 1
PDC20276: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xc400-0xc407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xc408-0xc40f, BIOS settings: hdg:pio, hdh:pio
VP_IDE: IDE controller at PCI slot 00:11.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1
ide4: BM-DMA at 0xd400-0xd407, BIOS settings: hdi:pio, hdj:pio
ide5: BM-DMA at 0xd408-0xd40f, BIOS settings: hdk:DMA, hdl:pio
hda: no response (status = 0xfe)
hdc: no response (status = 0xfe)
hde: IC35L090AVV207-0, ATA DISK drive
hdf: IC35L090AVV207-0, ATA DISK drive
blk: queue c03ff0f8, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c03ff238, I/O limit 4095Mb (mask 0xffffffff)
hdg: IC35L090AVV207-0, ATA DISK drive
hdh: IC35L090AVV207-0, ATA DISK drive
blk: queue c03ff554, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c03ff694, I/O limit 4095Mb (mask 0xffffffff)
hdk: DV-516E, ATAPI CD/DVD-ROM drive
ide2 at 0xb400-0xb407,0xb802 on irq 10
ide3 at 0xbc00-0xbc07,0xc002 on irq 10
ide5 at 0x170-0x177,0x376 on irq 15
hde: attached ide-disk driver.
hde: host protected area => 1
hde: 160836480 sectors (82348 MB) w/1821KiB Cache, CHS=10011/255/63,
hdf: attached ide-disk driver.
hdf: host protected area => 1
hdf: 160836480 sectors (82348 MB) w/1821KiB Cache, CHS=10011/255/63,
hdg: attached ide-disk driver.
hdg: host protected area => 1
hdg: 160836480 sectors (82348 MB) w/1821KiB Cache, CHS=10011/255/63,
hdh: attached ide-disk driver.
hdh: host protected area => 1
hdh: 160836480 sectors (82348 MB) w/1821KiB Cache, CHS=10011/255/63,
hdg: hdg1 hdg2
hdh: hdh1 hdh2
ide: late registration of driver.
bis dahin/kind regards
Official Webmin/Usermin Translation Co-Ordinator 2003/2004
I just tried installing Fedora Core 1 from CD-ROM on a K6-2 333 machine.
It has a Kyro 3D card, SCSI adaptor with non bootable CD drive, sound
blaster and network card. As the SCSI CD isn't bootable I had plugged an
IDE drive in to install from.
The install went fine up till the end where it hung on "finishing..."
(as the install was done in French I don't have the english text). The
only issue was the video card wasn't recognised so vesa driver was used.
OK so reset and... nothing. No BIOS screen, no hard disk activity. The
only things showing any life were the two CD-ROM drives which were
Power off - power on nothing the machine is dead.
Any clues? Coincidence or "something bad happened during install" TM?
www.tgds.net Library management software toolkit
There is an incompatibility between the flac package from Fedora Core
development tree and the flac package from fedora.us:
while flac-1.1.0-3.src.rpm from Fedora Core devel tree consists of flac,
flac-devel and flac-xmms the package from fedora.us splits this further by
generating the flac-libs package.
The Fedora Core devel tree approach is used by Freshrpms too so currently
people who use Fedora.us and Freshrpms are affected. For instance I'm
packaging K3b which requires flac, but if someone is using both the freshrpms
and fedora.us/stable repositories this happens:
yum detects that k3b needs flac, it installs it from freshrpms(it seems
newer), but it detects at the same time that libFLAC.so.4 is needed which is
provided by fedora's flac-libs. Of course when trying to install both
packages yum fails. An workaround would be to issue "yum --exclude=flac-libs
install k3b", but this is rather an ugly hack.
I spoke with Matthias Saou (who maintains flac from freshrpms) and he agreed
to change his package if the flac package from devel tree will be splitted
into fedora-libs too.
While this might be a temporary problem between Freshrpms and Fedora.us,
things will get worse as soon as Fedora Core 2 will be released. I already
submitted a bug on fedora.us about this issue
( https://bugzilla.fedora.us/show_bug.cgi?id=1397 ) but since nobody answered
I followed Warren Togamy's advise and took the problem in here.
Is someone working on a H.323 gatekeeper that compiles (and works) on FC1
and higher and make it packageable?
All email sent to me is bound to the rules described on my homepage.
Don't meddle in the affairs of sysadmins,
for they are subtle and quick to anger.
Something that's been biting me ever since I switched to xorg-x11: my
USB mouse seems to stop working after a period of inactivity. Every
morning when I come in, I can no longer use it -- the cursor won't move.
If I try to Ctrl-Alt-Backspace, X will forever hang, even disregarding
kill -9 from a remote ssh session. Rebooting is the only thing that
helps (and then again, eth0 won't come up unless I boot to 1 first, and
ifup eth0 from there, then init 5).
I'm not sure if it's xorg-x11, or the kernel -- they have been upgraded
at the same time. The only thing indicating that this might be the
kernel is the fact that when I insert my usb-key after the same
inactivity, the little bulb on it shows no reaction, while usually after
a fresh boot it will go into a frenzy of blinking while kernel is
setting up usb-scsi and all.
Anyone has similar problems?
Konstantin ("Icon") Ryabitsev
Duke Physics Systems Admin, RHCE
I am looking for a job in Canada!