rawhide report: 20040524 changes
by Build System
Updated Packages:
Maelstrom-3.0.6-4
-----------------
* Sun May 23 2004 Florian La Roche <Florian.LaRoche(a)redhat.de>
- make some files again owned by root
SDL-1.2.7-4
-----------
* Mon May 24 2004 Thomas Woerner <twoerner(a)redhat.com> 1.2.7-4
- added requires for alsa-lib-devel (#123374)
* Wed Mar 31 2004 Harald Hoyer <harald(a)redhat.com> - 1.2.7-3
- fixed gcc34 compilation issues
* Wed Mar 10 2004 Thomas Woerner <twoerner(a)redhat.com> 1.2.7-2.1
- added buildrequires for alsa-lib-devel
- now using automake 1.5
dmalloc-5.3.0-1
---------------
* Sun May 23 2004 Florian La Roche <Florian.LaRoche(a)redhat.de>
- 5.3.0
kdeartwork-3.2.2-2
------------------
* Mon May 24 2004 Than Ngo <than(a)redhat.com> 3.2.2-2
- fix file conflict with other kde packages
kernel-utils-2.4-9.1.133
------------------------
* Tue May 11 2004 Arjan van de Ven <arjanv(a)redhat.com>
- remove dmidecode; the 2.6 kernel exports the info in sysfs
- include cpuspeed on all architectures
logwatch-5.1-4
--------------
* Mon May 24 2004 Joe Orton <jorton(a)redhat.com> 5.1-4
- stop logging access_log entries with 2xx response codes
rpmdb-fedora-2-0.20040524
-------------------------
19 years, 11 months
python dependency for packages
by Warren Togami
The below is an example of an explicit python dependency to
automatically Require a compatible version of python at build time, from
fedora.us python-bsddb for FC1. Any opinions if this is a good solution
in general for packages that require python?
<warren> %define pyver %(python -c 'import sys ; print sys.version[:3]')
<warren> %define pynext %(python -c 'print %{pyver} + 0.1')
<warren> Requires: python >= 0:%{pyver}, python < 0:%{pynext}
<warren> any idea why the < part?
<mschwendt> because it is expected to conflict with next version of python
<mschwendt> ehm, be incompatible, not conflict
<warren> why not python = %{pyver} then?
<mschwendt> because of minor python versions between %pyver and %pynext
<warren> are we talking Version changes?
<warren> 2.3.1 to 2.3.2?
<mschwendt> yes
<warren> And there's no python command that can display the major.minor
of the current python instead?
<warren> [warren@ibmlaptop warren]$ python -c 'import sys ; print
sys.version[:3]'
<warren> 2.3
<mschwendt> compare that with rpm -q --provides python
<mschwendt> e.g. python = 2.2.3-7
<warren> mschwendt, your explicit dependency is missing the trailing
-%{release}, then it compares only the %{version}
<mschwendt> the package requires python version X, with: 2.2 <= X < 2.3
<warren> argh... okay I understand now.
John Dennis wrote:
> Update of /cvs/pkgs/rpms/mailman
>
> Modified Files:
> mailman.spec
> Log Message:
> make python prereq be at least 2.3
>
>
>
> Index: mailman.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/mailman/mailman.spec,v
> retrieving revision 1.29
> retrieving revision 1.30
> diff -u -r1.29 -r1.30
> --- mailman.spec 19 May 2004 01:25:22 -0000 1.29
> +++ mailman.spec 20 May 2004 17:51:51 -0000 1.30
> @@ -40,7 +40,7 @@
> Summary: Mailing list manager with built in Web access.
> Name: mailman
> Version: 2.1.5
> -Release: 2
> +Release: 3
> Epoch: 3
> Group: Applications/Internet
> Source0: ftp://ftp.gnu.org/pub/gnu/mailman/mailman-%{version}.tgz
> @@ -57,8 +57,8 @@
> URL: http://www.list.org/
> BuildRoot: %{_tmppath}/%{name}-root
> Prereq: shadow-utils, /usr/bin/newaliases, /usr/bin/crontab, /sbin/chkconfig, /sbin/service
> -Requires: webserver, python >= 2.2.1, mktemp
> -BuildPrereq: python-devel >= 2.2.1
> +Requires: webserver, python >= 2.3, mktemp
> +BuildPrereq: python-devel >= 2.3
>
> %description
> Mailman is software to help manage email discussion lists, much like
> @@ -304,6 +304,9 @@
> %attr(0755 root root) /etc/rc.d/init.d/mailman
>
> %changelog
> +* Thu May 20 2004 John Dennis <jdennis(a)redhat.com> 3:2.1.5-3
> +- make python prereq be at least 2.3
> +
> * Tue May 18 2004 Jeremy Katz <katzj(a)redhat.com> 3:2.1.5-2
> - rebuild
>
>
19 years, 11 months
Re: Request for Packages in Fedora Core 3 -- "Pure" Qt "Killer Apps"
by Bryan Smith
Lurker butting in here ...
Steven Pritchard wrote:
> Personally, I think the major "problem" with Scribus is that it is a
> Qt app, not a KDE app, so it doesn't exactly integrate with any of the
> desktops available in FC.
Gareth Russell wrote:
> I agree that it should be included but probably not as a default
> application due to its Qt status. It just doesn't integrate with the
> Gnome environment which is default in Fedora i.e. no Drag and drop
> functionality as in KDE.
Peter Linnell wrote:
> The reason why Scribus is not a purely KDE app is the desire to retain
> cross-platform compatibility. Scribus is available for fink, I am
> testing it with Cygwin and a native Win32 port is underway. We could
> not do this as a pure KDE application.
Peter, I 100% agree with the decision to go "Pure" Qt.
I consider two "Killer Apps" with _no_ Microsoft (although there are 3rd
party equivalents for Windows) equal to Linux to exist:
1. Typeset: LyX ( http://www.lyx.org )
2. DTP: Scribus
LyX made the transition to a widget-independent codebase a couple of
years ago (it was XForms-based prior). The result was not only a
preference for Qt, but an Aqua-native version for MacOS X (
http://www.18james.com/lyx_on_aqua.html )! No X11 required (yes!).
Now there are still some licensing issues with the Windows version,
being that Qt/Win32 is not GPL. But it's still an option that has
_no_ dependencies (other than TeTeX for the language back-end), because
it uses "Pure" Qt.
Using "Pure" Qt, Scribus also has the same option. It can produce both
native Qt/UNIX and Qt/Mac versions that are fully GPL, as well as a
non-GPL Windows version using Qt/Win32 (non-GPL).
Now regarding DnD and GNOME integration, I can understand some
concerns. But I have to believe there is nothing stopping Troll Tech
and other Qt developers from adding the small amount of code to support
DnD and other GNOME integration, at least for Qt/UNIX? In fact, is
there such an effort underway or at least being suggested?
Just my thoughts. I don't see any reason to "KDE'ize" Lyx-Qt or Scribus
at all. There are many advantages to producing "Pure" Qt apps.
-- Bryan J. Smith, "Lurker" and anti-WP, pro-typeset/DTP advocate**
P.S. Steve -- I'll respond to your further comment about "Extras" in
another post (i.e., I want to start another thread).
**BIAS EXPLAINED:
I have _never_ been into "Word Processors" (WP) in general. I consider
the WP to be a pre-GUI approach to documentation.
Pre-GUI, Pre-PC was the age of typeset.
Post-GUI is the age of Desktop Publishing (DTP).
In addition to the fact that DTP was invented on the Mac, even the
first, acclaimed documentation program on Windows was Ami Pro -- also a
DTP. Although Ami Pro was somewhat simplistic, it was still more
powerful than MS Publisher today.
But, unfortunately, because of the proliferation of MS Word thanx to
Microsoft OEM bundling and rebates in the mid-'90s, most people have
never used either typeset or DTP. If you're lucky, you might meet
someone who has used MS Publisher. But because MS Publisher is an
elementary DTP, they dismiss it as "not powerful like MS Word."
MS Word attempts to be both a typeset and a DTP, and it is a bastard
that fails miserably at both. That's because it lacks a good,
underlying documentation language. Adobe FrameMaker, on the other hand,
does a fairly good job at both, because it does have an underlying
documentation language (even if not well documented).
There is no further proof in the capabilities of something like Adobe
FrameMaker v. MS Word than in Microsoft's own _preference_ for
FrameMaker for MS Office documentation. Oh the irony! [ I regualrly
use that argument, often in a losing fashion, when I am "forced" to
write 200+ page technical manuals at companies in MS Word -- Grrrrr! ]
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Re: Request for Packages in Fedora Core 3
by Gareth Russell
> Scribus - The first modern DTP package for Linux. This is an
> essential for myself and many others moving from commercial
> operating systems. More than any other package, I would love to see
> this included. It will help you win converts...
I agree that it should be included but probably not as a default
application due to its Qt status. It just doesn't integrate with the
Gnome environment which is default in Fedora i.e. no Drag and drop
functionality as in KDE.
> KIllustrator or Sketch - Vector graphics would be very good. I
> understand one of these products has as much functionality as GIMP but I
> am not sure which. Open Office's drawings do not suffice.
I think you're referring to Sketch. Again Sketch would be a better
choice over the KDE app.
> Ardour or Audacity for audio manipulation.
Agreed - some good music/audio apps would add more depth to the packages
available and appeal to a certain niche.
Gareth
FedoraForum.org Administrator
19 years, 11 months
GRUB, fdisk/installers need to support the LDM disk label
by Bryan Smith
[ Before you trash this e-mail, please read it.
If you don't want to read it now, at least save it for later. ]
First off, this post was preceeded by two posts to Bugzilla 115980.
Specifically, my comments #62 and #63, which resulted in some direct
correspondence.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115980#c62
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115980#c63
TERMINOLOGY REFERENCE
- DOS Disk Label (pri/ext/log, "Basic" disk, "MBR" disk [label])
The legacy disk label (partition table) format of primary, extended and
logical. Microsoft refers to this format in NT 5.x (2000, XP, 2003) as
a "Basic" disk or a "MBR" disk [label]. I will use "DOS" disk label.
- LDM Disk Label ("Dynamic" disk, "LDM" disk [label])
The Microsoft Logical Disk Manager (LDM) in NT 5.x (2000, XP, 2003)
which looks like a single type 42h primary partition in a DOS disk
label. Microsoft also refers to it as a "Dynamic" disk or a "LDM"
disk [label]. It stores geometry, NTFS-SID references and other
goodies, much like any OS logical volume management (LVM) does.
MY RECOMMENDATIONS
At this time, I recommend the following efforts be put forth. I am
more than willing to bring myself up to speed and try to help out
(I am a meager C coder with a lot of experience in BIOS/disk geometry
issues).
1. GRUB be modified to support booting volumes in LDM disk labels
2. Util-linux's fdisk and Anaconda be modified to support creating
"simple" volumes in a LDM disk label, as well as the LDM disk label
itself
MY RATIONALE
A. The LDM disk label solves boot-time geometry issues with NT
(as well as countless other issues).
B. The LDM format is fairly well documented now
( http://linux-ntfs.sourceforge.net/ldm/index.html )
C. Linux kernels support loading/accessing volumes in LDM disk labels
already, including LVM/LVM2 and MD.
ADDITIONAL RECOMMENDATIONS
3. Installer prompts/info
a. On a new (blank) disk, the installer should let the user choose
between using the legacy DOS or newer LDM disk label, and tell the user
why.
b. On an existing, legacy DOS disk label, if the installer detects NT
5.x, it should recommend the user boot into NT 5.x+ and convert to a LDM
disk label (dynamic disk) before installing Linux.
ADDITIONAL RATIONALE
D. Microsoft is pushing LDM adoption hard, largely because it solves
such geometry issues with itself (e.g., booting multiple NT 5.x+
versions).
E. The LDM disk label is recommended when you read NTFS filesystems
from an OS installation that did not create the NTFS volume. I.e., you
should _never_ write to a NTFS volume from even another NT installation
because of the SID mapping issues in a NTFS volume -- _unless_ a LDM
disk label is used (which can store these mappings outside the
registry). Yes, NTFS write support is an issue with NT itself, if the
NT installation did not create the NTFS volume being written to (because
of the registry/SID issues).
MY COMMENTARY
God knows this was much easier back in the DOS/Win (95, 98, ME) days
where DOS/Win wouldn't even boot if the BIOS and disk label geometry
didn't match. But now we're onto NT en-masse.
In a nutshell, yes, Microsoft should have created a mature NT kernel
that can read the DOS disk label geometry and compare/ignore the BIOS.
I have advocated this for a long time (being an original NT 3.1 beta
tester myself). But they have not.
Additionally, Microsoft never considered the issues with writing to NTFS
filesystems that were not created by the NT installation writing to it.
You can (and I have) _toasted_ NTFS filesystems when writing to them
from a NT installation
_Both_ of these issues are _solved_ by using the LDM disk label. Now
I'm not advocating we have Linux be able to do all sorts of LDM
manipulation. But it would be nice if, again:
1. GRUB was modified to boot volumes inside of LDM disk
2. Linux fdisk/installers could at least create "Simple" volumes inside
of LDM disk labels (as well as a new LDM disk label itself)
Now #1 could be "put off" for a bit, since LILO (being dumb and a simple
"sector reference") _can_ boot volumes inside of LDM disk labels (at
least Linux, but NT 5.x too?). But ultimately extensible GRUB should be
able to do this, correct?
POTENTIAL GOTCHAS
Microsoft does not support the LDM disk label on the following storage
devices:
- Notebooks (WTF? They are the biggest geometry nightmares!)
- Removable drives (CD-RW, DVD-RAM/RW/+RW, etc...)
- External drives (IEEE1394, USB)
- External solid state storage (flash cards, sticks, etc...)
The latter three items are not much of a big deal. But notebooks, those
are a "sticking point." Why did Microsoft not support LDM on them?
Probably because of the "suspend partition" that some use? I'm not
sure.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Choosing rpm-release for fc1 and fdr add-on rpms
by Ralf Corsepius
Hi,
I am planing to release a couple of rpms which are supposed to be add-on
packages to Fedora Core and/or Fedora Extras.
What is the current convention on choosing rpm release tags for such
packages to provide co-existence for such kind of packages?
AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
such kind of convention. Conversely, all seem to be designed "to take
over the system".
Ralf
19 years, 11 months
rawhide report: 20040523 changes
by Build System
Updated Packages:
kernel-2.6.6-1.377
------------------
mdadm-1.5.0-9
-------------
* Sat May 22 2004 Doug Ledford <dledford(a)redhat.com> - 1.5.0-9
- Fix Makefile and build method to satisfy bz #123769
- Add mdmpd man page, update mdmpd version to 0.3 - bz #117160
- Make sure mdadm --monitor closes all md device files so that md devices
can be stopped while mdadm is still running - bz #119532
rpmdb-fedora-2-0.20040523
-------------------------
19 years, 11 months
Request for Packages in Fedora Core 3
by dlesage@iprimus.com.au
Hello All,
I am really enjoying my use fo Fedora Core 2. To make the next release
even better, I humbly request the following packages be considered for
inclusion:
Scribus - The first modern DTP package for Linux. This is an
essential for myself and many others moving from commercial
operating systems. More than any other package, I would love to see
this included. It will help you win converts...
KIllustrator or Sketch - Vector graphics would be very good. I
understand one of these products has as much functionality as GIMP but I
am not sure which. Open Office's drawings do not suffice.
Ardour or Audacity for audio manipulation.
Please keep up the excellent work.
Regards,
David
19 years, 11 months
Sorry...
by Stan Bubrouski
Hey,
Sorry I haven't been very polite on these lists lately, and I've been
more than a little unfair to Warren Togami specifically. And I know its
totally my fault. I'm man enough to admit it.
But can someone point me to a place where it tells with specificity what
should be asked on what list? Seems like even people who run the lists
are sometimes unclear on where certain topics should end up. I realize
that not everything is appropriate for these lists, but I'd like to have
my questions answered and so I'd like to know for certain what list is
for what...
Are their charters or anything anywhere?
Best Regards,
Stan Bubrouski
PS. Sorry again Warren, I know I'm a complete tool sometimes.
19 years, 11 months