devel September 2003

devel@lists.fedoraproject.org

139 participants
90 discussions

Compiling plotutils on RHL 9 fails
by Jos Vos 14 Sep '03

14 Sep '03

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

2 2

Argument list too long.
by Dag Wieers 14 Sep '03

14 Sep '03

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]

8 25

Split redhat-artwork
by Peter Backlund 13 Sep '03

13 Sep '03

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

1 0

using the uname() function
by Fred Bartholomai 13 Sep '03

13 Sep '03

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

3 2

UML project for Cambridge++
by M A Young 12 Sep '03

12 Sep '03

I am trying to put together a Red Hat Linux Project project to develop User Mode Linux aiming for inclusion in Cambridge++. I don't know how this is supposed to work (I am not sure anyone does yet), but I have put together an initial project page at http://toast.debian.net/~may/umlproject/index.html Michael Young

4 6

%post -p /sbin/ldconfig
by Michael Schwendt 11 Sep '03

11 Sep '03

-----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-----

1 1

RAID5 + LVM and (varying) blocksizes
by Jos Vos 11 Sep '03

11 Sep '03

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

1 0

Third Party Licensing Software
by Fred Bartholomai 10 Sep '03

10 Sep '03

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

3 2

CD burning with Nautilus, was: Why xcdroast and not gcombust?
by Nils Philippsen 09 Sep '03

09 Sep '03

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

8 17

ANNOUNCENEMENT: release of mach 0.4.0 "Barcelona"
by Thomas Vander Stichele 08 Sep '03

08 Sep '03

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/

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2003