Compiling plotutils on RHL 9 fails
by Jos Vos
Hi,
Plotutils 2.4.1 with --enable-libplotter doesn't compile in RHL 9.
This is what I get:
c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I./../include -DLIBPLOT -DLIBPLOTTER -O2 -g -pipe -march=i386 -mcpu=i686 -c g_write.cc -fPIC -DPIC -o .libs/g_write.lo
In file included from /usr/include/c++/3.2.2/backward/iostream.h:31,
from ../include/plotter.h:61,
from extern.h:44,
from g_write.cc:5:
/usr/include/c++/3.2.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated.
g_write.cc: In function `void _write_bytes(const plPlotterData*, int, const
unsigned char*)':
g_write.cc:43: invalid conversion from `const unsigned char*' to `const char*'
g_write.cc:43: initializing argument 1 of `std::basic_ostream<_CharT,
_Traits>& std::basic_ostream<_CharT, _Traits>::write(const _CharT*, int)
[with _CharT = char, _Traits = std::char_traits<char>]'
make[2]: *** [g_write.lo] Error 1
make[2]: Leaving directory `/home/jos/lx/rpm8/BUILD/plotutils-2.4.1/libplotter'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jos/lx/rpm8/BUILD/plotutils-2.4.1'
make: *** [all-recursive-am] Error 2
Anyone having a patch for this?
Thanks,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
20 years, 7 months
Argument list too long.
by Dag Wieers
Hi,
I'm wondering if option 4 from the following article
Linux Journal: "Argument list too long": Beyond Arguments and Limitations
http://www.linuxjournal.com/article.php?sid=6060
could be done for the Red Hat kernel (or the vanilla kernel) and if not,
what the objections are.
Linux Journal suggests to increase the MAX_ARG_PAGES from 32 to 64
pages in include/linux/binfmts.h:
/*
* MAX_ARG_PAGES defines the number of pages allocated for arguments
* and envelope for the new program. 32 should suffice, this gives
* a maximum env+arg of 128kB w/4KB pages!
*/
#define MAX_ARG_PAGES 32
I'm not in favor to increase it to 64 per se, but at least something
higher than 32 (as I've already come across this boundary at several
occassions where the only solution was to work around it in a bad way).
Maybe make it system dependent or even dynamically changeable.
Kind regards,
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
20 years, 7 months
Split redhat-artwork
by Peter Backlund
Hi.
Would it be possible to split the redhat-artwork package into a KDE/QT part
and an everything-else part? It would be great for things like the kde-redhat
project (kde-redhat.sf.net), being able to rebuild affected parts for newer
KDE/QT releases without having to touch the gtk stuff.
Besides, is it legal, trademark-wise, for them to distribute the
redhat-artwork package?
/Peter Backlund
20 years, 7 months
using the uname() function
by Fred Bartholomai
On HP-UX we use the uname() function in our own proprietary licensing
software
Which we have developed. One of the values it returns is the 'idnumber',
Which contains a unique identification number for each physical machine
in which it is run.
Using this same function on Red Hat 8.0 the 'idnumber' field does not
exist.
Does anyone know of an alternative way of getting such a idnumber ?
I've been doing some searching and have not come up with anything.
Thank you,
Fred Bartholomai
----------------------------------------------------
Fred Bartholomai
Advanced Control Systems, Inc.
Software Dept., R&D Consultant
770 849 0131 x334
fred.bartholomai(a)acsatl.com
20 years, 7 months
%post -p /sbin/ldconfig
by Michael Schwendt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Severn with updates, I just noticed the following changed behaviour
with regard to using /sbin/ldconfig as script processor in RPM
scriplets:
# ldconfig 0
ldconfig: relative path 0' used to build cache
# ldconfig 1
ldconfig: relative path 1' used to build cache
Consequently, all "-p /sbin/ldconfig" scriplets print that
warning/error. This is with
$ rpm -q glibc
glibc-2.3.2-78
Has anyone any insight into what is going on here? If this will
stay like that, it means "bye, bye" to -p /sbin/ldconfig.
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/X2bE0iMVcrivHFQRAgq3AJ9h+i3qHkGqpgMBYKl7qqeZwsefEwCfbQOm
XhrxPgErmvxFPMWaLbYtayw=
=kjG3
-----END PGP SIGNATURE-----
20 years, 7 months
RAID5 + LVM and (varying) blocksizes
by Jos Vos
Hi,
When using a LVM VG *on top of* a Linux RAID5 device (a *very* useful
combination, IMHO), I get tons of kernel messages like
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 1024
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 4096
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 1024
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 1024 --> 4096
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 4096
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 1024
Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 1024 --> 4096
in the following cases:
(1) While creating the LV.
(2) While mke2fs'ing an ext3 fs on the LV.
(3) Using an ext3 fs ob the LV when the blocksize is 1K (and the
rest of the ext3 fs's on that VG have a 4K block size).
In the meantime I understood the reason (RAID5 always wants to see the
same blocksize for I/O operations). Cases (1) and (2) are not a real
problem (although creating a 500 GB ext3 fs takes about 1 hour!!!),
because you do it only once, and (3) is avoidable, so my question is:
When I use LVM on top of RAID5 and I use it only for swap LV's (swap
devices use 4K pages anyway, isn't it?) and ext3 filesystems with a
block size of 4K, can I trust that this will cause no future problems
and will work efficiently?
Thanks,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
20 years, 7 months
Third Party Licensing Software
by Fred Bartholomai
Is anyone familiar with any Third-Party Licensing Software that will run
on Red Hat Linux Enterprise WS 2.1 ?
Thanx,
Fred Bartholomai
----------------------------------------------------
Fred Bartholomai
Advanced Control Systems, Inc.
Software Dept., R&D Consultant
770 849 0131 x334
fred.bartholomai(a)acsatl.com
20 years, 7 months
CD burning with Nautilus, was: Why xcdroast and not gcombust?
by Nils Philippsen
Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
> One comment about the current music cd burning abilities. This is very
> limiting and will in the future be removed in favour of a "burn
> playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife
where she would look for something to burn her music on CD and it was
definitely not the music player -- and she is an end user (beat this
;-). Funny enough, she would expect a CD-burning application which kinda
makes sense since the task probably gets perceived rather as "burn a CD"
(with whatever contents) than as "do XYZ with my music" or "do XYZ with
my data" -- putting a medium in the drive could be more "tangible" than
shuffling bits around, but I'm getting philosophic...
> There just isn't any sane way to handle ordering of the songs in the
> nautilus UI. Plus you want to know things like total play time and have
> easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything):
Would it be that hard to implement a new Nautilus view which were aware
of ordering and other stuff needed for that? Of course (Havoc will hate
that) it would need to expose some of the innards of audio CDs and
CD-ROMs, red, orange and other coloured books to the user, but I guess
this could be done easy for easy tasks (copying whole audio+data CDs,
burning ISOs, burning just data) and still provide means to do more
sophisticated stuff...
But probably I'm the wrong person to ask -- getting ACL support into
Nautilus wasn't as easy as I thought either ;-). If it'd be doable, I'd
try my luck though (if time permits).
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
20 years, 7 months
ANNOUNCENEMENT: release of mach 0.4.0 "Barcelona"
by Thomas Vander Stichele
I've just released mach 0.4.0 - it might interest you because it's a
very useful tool to write clean spec files and build clean packages.
Please give it a spin, read the README and these release notes, and
experiment. I appreciate all feedback, good bad, or ugly bugs.
mach - make a chroot - RELEASE NOTES
------------------------------------
Announcing the release of mach 0.4.0 - "Barcelona"
WHAT IS IT
----------
mach allows you to set up clean roots from scratch for any distribution
or distribution variation supported.
This clean build root can be used to run jailed services, create disk
images, or build clean packages.
mach can currently set up roots for the following distributions:
- Red Hat 7.2 (basic, updated, FreshRPMS)
- Red Hat 7.3 (basic, updated, FreshRPMS)
- Red Hat 8.0 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS)
- Red Hat 9 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS)
- SuSE 8.1/8.2
- Dave/Dina oven/fridge
Read the README included in the distribution for a better overview.
WHY WOULD YOU USE IT
--------------------
mach is helpful:
- to create minimal chroot environments to jail services in
- to create clean packages for distributions
- to catch spec file mistakes, missing buildrequires, and more
INFORMATION
-----------
mach's homepage is at http://thomas.apestaart.org/projects/mach/
mach is hosted on SourceForge; the project page is
http://www.sourceforge.net/projects/mach/
QUICKSTART
----------
a) On a Red Hat 9 system, install the mach rpm from
http://thomas.apestaart.org/download/mach
b) su - mach
c) mach setup base
d) mach chroot
poke around a bit in the fresh root
e) exit
f) mach rebuild
http://ayo.freshrpms.net/redhat/9/i386/SRPMS.os/vorbis-tools-1.0-3.src.rpm
If all goes well, you'll get a nice freshly built vorbis-tools package.
Now go out, experiment and bug report !
BUGS
----
Please report all bugs to me at thomas (at) apestaart (dot) org.
Always state what platform you are running on, if it's a clean install
or somehow updated, how I can reproduce the bug, and output of a run of
the failed command with -d (debugging).
Thomas
Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
You take it in stride but still
You fall as you're walking
Big sky above me a river inside me and I'm
Doubled up in love
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
20 years, 7 months