Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Adam H. Pendleton wrote: Jean-Michel POURE wrote: A lot more. A least, expat-devel, pango-devel, zlib-devel, X11-foo-devel, iconv-devel, etc... See the list below. Under SuSE and Mandrake, many of these libraries have different naming schemes. I may be wrong on this one, but I don't think there's any need to list these dependencies in the BuildRequire line. For example, by adding gtk2-devel, we implicity add these packages: Hi Adam, Jean-Michel, I think Adam is right regarding dependencies, it's not usefull (and can get you to mistake if packages change) to specify all these dependencies. FYI Debian's dependencies I use are these (I cut debian specific things) Build-Depends: libgtk2.0-dev, gcc, g++, libjpeg62-dev, libpng-dev (>> 1.2.0) | libpng12-dev (>> 1.2.0) | libpng2-dev , libtiff3g-dev Isn't there a way to specify expressions like "or" (the '|' in debian) in rpms specs files ? That's what I used to solve the problem of package names changing from stable to testing and unstable. What do you mean by automatic binary dependencies? I thought that RPM dependencies were enforced by the "Requires:" line in the spec file. concerning this I find that RPM is too "agressive" while looking for dependencies. I'm not an RPM expert but when I do rpms packages I always do a first shot as is (without specifying anything) and I look to the result. Then I specify directly in the spec file not to look for dependencies and hard code them by hand. The "magic" flag is : AutoReqProv: no (http://linux.tnc.edu.tw/techdoc/maximum-rpm/rpmbook/node310.html). Regards, Raphaël ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Adam H. Pendleton wrote: So are we going to be using the official wxWindows RPMs from now on? Are we going to run into any problems since we currently use a build of wxWindows that differs from the "official" build? Still absolutely no, there's not a haze of work in committing my patches, not even commenting on it. If it makes sense, we'll snapshot whatever is agreed to work nicely for us, and then we'll add our own patches. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Hi Adam, Thanks for your explainations. The gtk-devel seems convincing. But there are other libraries. Feel free to submit a patch and I will integrate it immediately. > What do you mean by automatic binary dependencies? I thought that RPM > dependencies were enforced by the "Requires:" line in the spec file. If you do not write any "Requires:" line, RPM does it for you automatically. Cheers, Jean-Michel ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Jean-Michel POURE wrote: A lot more. A least, expat-devel, pango-devel, zlib-devel, X11-foo-devel, iconv-devel, etc... See the list below. Under SuSE and Mandrake, many of these libraries have different naming schemes. I may be wrong on this one, but I don't think there's any need to list these dependencies in the BuildRequire line. For example, by adding gtk2-devel, we implicity add these packages: [EMAIL PROTECTED] Development]$ rpm -qR gtk2-devel XFree86-devel atk-devel >= 1.0.0-1 glib2-devel >= 2.2.0-1 gtk2 = 2.2.4 libc.so.6 libc.so.6(GLIBC_2.0) libdl.so.2 libgdk_pixbuf-2.0.so.0 libglib-2.0.so.0 libgmodule-2.0.so.0 libgobject-2.0.so.0 libm.so.6 pango-devel >= 1.2.0-3 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 [EMAIL PROTECTED] Development]$ In order to get gtk2-devel installed, these packages would also have to be installed. Also, any packages that those listed packages depend on would also have to be installed. Thus, by putting just gtk2-devel on the BuildRequires line, we implicity pull in the whole dependency tree for that package. Since RPMs have automatic binary dependencies, looking at the SRPM rebuild log is enough for me ... All libraries should display "yes" or "sys". What do you mean by automatic binary dependencies? I thought that RPM dependencies were enforced by the "Requires:" line in the spec file. ahp
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Dear Adam, > Really? Am I missing something, or would this line suffice (granted, > this is the RH line, but...): > BuildRequires: gtk2-devel, libjpeg-devel, libpng-devel, libtiff-devel A lot more. A least, expat-devel, pango-devel, zlib-devel, X11-foo-devel, iconv-devel, etc... See the list below. Under SuSE and Mandrake, many of these libraries have different naming schemes. Since RPMs have automatic binary dependencies, looking at the SRPM rebuild log is enough for me ... All libraries should display "yes" or "sys". >So are we going to be using the official wxWindows RPMs from now on? >Are we going to run into any problems since we currently use a build of >wxWindows that differs from the "official" build? wxGTK-2.5.1 stable "official" release is not out yet. No idea when it will be released. The next official wx release has very designed RPM build scripts. I modified the scripts very slightly here: http://snake.pgadmin.org/jean-michel/makerpm.new Cheers, Jean-Michel *** saving argument cache configarg.cache checking for toolkit... gtk checking for i686-pc-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for i686-pc-linux-gnu-g++... no checking for i686-pc-linux-gnu-c++... no checking for i686-pc-linux-gnu-gpp... no checking for i686-pc-linux-gnu-aCC... no checking for i686-pc-linux-gnu-CC... no checking for i686-pc-linux-gnu-cxx... no checking for i686-pc-linux-gnu-cc++... no checking for i686-pc-linux-gnu-cl... no checking for i686-pc-linux-gnu-FCC... no checking for i686-pc-linux-gnu-KCC... no checking for i686-pc-linux-gnu-RCC... no checking for i686-pc-linux-gnu-xlC_r... no checking for i686-pc-linux-gnu-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... /usr/bin/install -c checking for strip... strip checking if make is GNU make... yes checking whether ln -s works... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking for unistd.h... (cached) yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking fnmatch.h usability... yes checking fnmatch.h presence... yes checking for fnmatch.h... yes checking for fnmatch... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking X11/Xlib.h usability... yes checking X11/Xlib.h presence... yes checking for X11/Xlib.h... yes checking for X11/XKBlib.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for void *... yes checking size of void *... 4 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking size of wchar_t... 4 checking for _FILE_OFFSET_BITS value needed for large files... 64 checking if large file support is available... yes checking whether byte ordering is bigendian... no checking how to run the C++ preprocessor... g++ -E checking iostream usability... yes checking iostream presence... yes checking for iostream... yes checking if C++ compiler supports bool... yes checking if C++ compiler supports the explicit keyword... yes checking whether the compiler supports const_cast<>... yes checking for glibc 2.1 or later... yes checking regex.h usability... yes checking regex.h presence... yes checking for regex.h... yes checking for regcomp... yes checking for zlib.h >= 1.1.4... yes checking for zlib.h... (cached) yes checking for deflate in -lz... yes checking for png.h > 0.90... yes checking for png.h... (cached) yes checking for png_check_sig in -lpng... yes checking for jpeglib.h... yes checking for jpeg_read_header in -ljpeg... yes checking tiffio.h usability... yes checking tiffio.h presence... yes checking for tiff
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Jean-Michel POURE wrote: Yes, it is perfectly possible. But, there are so many-many build-time depencies in wxWindows. Listing them all is quite difficult. Really? Am I missing something, or would this line suffice (granted, this is the RH line, but...): BuildRequires: gtk2-devel, libjpeg-devel, libpng-devel, libtiff-devel On the other hand, the upcoming stable version of wxWindows 2.5.1 will provide a new set of RPMs. These "new" RPMs are very well designed. They include both buildtime and binary dependencies. Personaly, I think it is a waste of time to invest in the wxGTK2ud direction when a new set of RPMs is coming along. If you think the converse, do not hesitate to submit a patch and I will apply it immediately. This is free software... You are free to do what you want... So are we going to be using the official wxWindows RPMs from now on? Are we going to run into any problems since we currently use a build of wxWindows that differs from the "official" build? ahp
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Le Lundi 17 Novembre 2003 19:44, vous avez écrit : > I realize it's a pain, but is it not possible to work the different sets > of BuildRequires into the spec file, using distribution-dependent > conditional statements? Yes, it is perfectly possible. But, there are so many-many build-time depencies in wxWindows. Listing them all is quite difficult. On the other hand, the upcoming stable version of wxWindows 2.5.1 will provide a new set of RPMs. These "new" RPMs are very well designed. They include both buildtime and binary dependencies. Personaly, I think it is a waste of time to invest in the wxGTK2ud direction when a new set of RPMs is coming along. If you think the converse, do not hesitate to submit a patch and I will apply it immediately. This is free software... You are free to do what you want... Cheers, Jean-Michel ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies
Jean-Michel POURE wrote: Dear Devrim, Finally, I commented out the BuildRequires dependencies for wxGTK2ud in CVS. It appears that library names needed at build time are not the same under RedHat, Mandrake and SuSE. So, my 'stupid' recommended way is: rpmbuild --rebuild wxGTK2ud-2.5-.src.rpm 2>&1 | tee wxGTK2ud-2.5-.log I realize it's a pain, but is it not possible to work the different sets of BuildRequires into the spec file, using distribution-dependent conditional statements? and read the log to make sure all needed libraries display 'sys'. Do not hesitate to send me by email the wxGTK2ud (with 'sys' libraries) and pgAdmin3 (S)RPMs and I will publish them in a new Fedora section. Do not hesitate to sign your email with OpenPGP. By the way, would you be interested in releasing daily snapshots for Fedora? We always need help... Incidentally, why are we building snapshots specifically for FC1? Is there a problem with the binary RPMs on Fedora? I have built the SRPMs with no trouble. ahp ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
