Re: Passing variables to a Makefile
Charles Plessy schrieb: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? ( Just in case one wants to see more context, I have uploaded the package on mentors: http://mentors.debian.net/debian/pool/main/d/dialign-t/dialign-t_0.2.2-1.dsc It is work in progress unsuitable for anyghing else! ) Have a nice day, Hi Charles, better use a patch system like dpatch for it. Don't modify the source, write a patch for it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
2007/10/11, Charles Plessy [EMAIL PROTECTED]: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? It seems OK for me, I usually do it that way too. You can also alternatively override the variable sending it as a parameter for make: $(MAKE) -C source CPPFLAGS='$(CFLAGS)' But in my opinion both ways are equivalent in this case. I did not have time to have a look at the package anyway, so I haven't tested it. I'm quite too busy these days, sorry. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx This is obviously not convenient for building on many platforms, so I decided to override it with the following command in debian/rules: CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source $(MAKE) -C source CPPFLAGS='$(CFLAGS)' However, I am quite unexperienced with makefiles, and my gut feeling tells me that I may be doing something wrong... Can somebody tell me ? ( Just in case one wants to see more context, I have uploaded the package on mentors: http://mentors.debian.net/debian/pool/main/d/dialign-t/dialign-t_0.2.2-1.dsc It is work in progress unsuitable for anyghing else! ) One issue in debian/rules: + install -o 755 source/dialign-t debian/dialign-t/usr/bin/ + dh_install conf/* usr/share/dialign-t You mean `install -m'. -o sets the ownership. However, you can safely use dh_install here, because dh_fixperms (binary-arch target) will set the right permissions. You further don't need to run dh_installdirs for directories, used in dh_install. The latter will automatically care about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: polipo (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0.3-1 of my package polipo. It builds these binary packages: polipo - a small, caching web proxy The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/polipo - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/polipo/polipo_1.0.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards Denis Sirotkin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mad promo!
Our X X X Network for FREE today! www madpromo dot cn subtractors monosiphonic Altair blubbers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert wrote: Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. I guess this is handled too by install -D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. So it's supposed to have things like -Iinclude -DFOO=BAR. CFLAGS is for the C compiler itself, so it's supposed to have things like -O3 -funroll-loops -std=gnu99 -Wall -Wextra. But it only matters if you're using the implicit rules and the binaries are built from multiple source files or are otherwise compiled and linked in separate invocations. BTW there's LDFLAGS too for linker options like -Wl,-soname,libfoo.so.1 -Wl,-O2 (here it's assumed that LD=gcc thus the -Wl, thing). I think that Debian packages shouldn't have subarch-specific options on any arch, since the same binaries may/(have to be able to) be run on variation on that arch. In the case of i386, the binaries have to be able to run on a real 386 [0]. I think all the arch options here will (maybe) cause the binary to fail on such a machine. Justin [0] My understanding is that the packaged kernels don't support 386 but with a software emulation of some math instruction patched in, 386 is advertised as being supported with binary packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
binary-or-shlib-defines-rpath error message
hi i am a newbee in packaging and trying out how to package some already available source packages i am trying to pack jpeg62_6b, the package builds successfully but running lintian shows binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib the message is same for all binaries in /usr/bin can some one please explain the reason for this message? Also while building the same package a warning message is being displayed by dh_shlibdeps here is the message:: dpkg-shlibdeps -Tdebian/libjpeg62-utils.substvars debian/libjpeg62-utils/usr/bin/cjpeg debian/libjpeg62-utils/usr/bin/djpeg debian/libjpeg62-utils/usr/bin/rdjpgcom debian/libjpeg62-utils/usr/bin/wrjpgcom debian/libjpeg62-utils/usr/bin/jpegtran dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 dpkg-shlibdeps: warning: could not find any packages for (libjpeg.so.62) dpkg-shlibdeps: warning: unable to find dependency information for shared library libjpeg (soname 62, path , dependency field Depends) dpkg-shlibdeps: warning: could not find any packages for (libjpeg.so.62) dpkg-shlibdeps: warning: unable to find dependency information for shared library libjpeg (soname 62, path , dependency field Depends) dpkg-shlibdeps: warning: could not find any packages for (libjpeg.so.62) dpkg-shlibdeps: warning: unable to find dependency information for shared library libjpeg (soname 62, path , dependency field Depends) what i figured out that the binaries that are getting installed are linking to the library the package will produce. Any means to provide such kind of information? thanks and regards varun -- View this message in context: http://www.nabble.com/binary-or-shlib-defines-rpath-error-message-tf4607195.html#a13155621 Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
On Thu, Oct 11, 2007 at 06:17:06AM -0700, varun_shrivastava wrote: hi i am a newbee in packaging and trying out how to package some already available source packages i am trying to pack jpeg62_6b, the package builds successfully but running Is this the same package that caused dh_strip errors? lintian shows binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib the message is same for all binaries in /usr/bin You shouldn't set rpath to /usr/lib since it's in the default search path. can some one please explain the reason for this message? Debian considereds rpath to be inflexible. Also while building the same package a warning message is being displayed by dh_shlibdeps here is the message:: dpkg-shlibdeps -Tdebian/libjpeg62-utils.substvars debian/libjpeg62-utils/usr/bin/cjpeg debian/libjpeg62-utils/usr/bin/djpeg debian/libjpeg62-utils/usr/bin/rdjpgcom debian/libjpeg62-utils/usr/bin/wrjpgcom debian/libjpeg62-utils/usr/bin/jpegtran dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 You have to supply a ./debian/shlibs file in any package that includes public shared libraries (/usr/lib/*.so.*). It gets installed to /usr/lib/dpkg/info/ and searched by dh_shlibdeps when building packages to find on what package,version to add a dependency for a given objdump -p |grep -we NEEDED line. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: polipo (updated package)
Hi Denis! On 10/11/07, DS [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 1.0.3-1 of my package polipo. Actually you didn't change the watch file, as you have described in your changelog :-) Best regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
Le Thursday 11 October 2007 15:17:06 varun_shrivastava, vous avez écrit : hi Hi ! i am a newbee in packaging and trying out how to package some already available source packages i am trying to pack jpeg62_6b, the package builds successfully but running lintian shows binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib the message is same for all binaries in /usr/bin can some one please explain the reason for this message? rpath specifies where to find the required library. Debian wants *not* to use it since it messes with library update: one may want to move the library to a new place without breaking binaries depending on it. Also while building the same package a warning message is being displayed by dh_shlibdeps here is the message:: dpkg-shlibdeps -Tdebian/libjpeg62-utils.substvars debian/libjpeg62-utils/usr/bin/cjpeg debian/libjpeg62-utils/usr/bin/djpeg debian/libjpeg62-utils/usr/bin/rdjpgcom debian/libjpeg62-utils/usr/bin/wrjpgcom debian/libjpeg62-utils/usr/bin/jpegtran dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 dpkg-shlibdeps: warning: could not find any packages for (libjpeg.so.62) dpkg-shlibdeps: warning: unable to find dependency information for shared library libjpeg (soname 62, path , dependency field Depends) dpkg-shlibdeps: warning: could not find any packages for (libjpeg.so.62) dpkg-shlibdeps: warning: unable to find dependency information for shared library libjpeg (soname 62, path , dependency field Depends) dpkg-shlibdeps: warning: could not find any packages for (libjpeg.so.62) dpkg-shlibdeps: warning: unable to find dependency information for shared library libjpeg (soname 62, path , dependency field Depends) what i figured out that the binaries that are getting installed are linking to the library the package will produce. Any means to provide such kind of information? shlibdeps looks for libraries that the binary requires and add the coresponding package to the dependencies of the binary package. This loooks like you have several version of this library installed, like one in /usr/local/lib, compiled by yourself, and it screw up shlibdeps since it cannot find a package for it. Romain
Re: Passing variables to a Makefile
Am Donnerstag, den 11.10.2007, 08:15 -0400 schrieb Justin Pryzby: On Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert wrote: Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. I guess this is handled too by install -D. It is. But many users miss it and then the package FTBFS because of the non-existing target directory. However, install is only useful, if you have to rename the source or if you have to set special permissions, not handled by dh_fixperms. I often miss the possibility to use this dehelper script with: dh_fixperms $target $permissions IMHO this would reduce the necessity to use chmod or install in debian/rules. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nted (2nd try)
Dear mentors, I am looking for a sponsor for my package nted. * Package name: nted Version : 0.7.0-1 Upstream Author : Jörg Anders [EMAIL PROTECTED] * URL : http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted.xhtml * License : GPL Section : sound It builds these binary packages: nted - Musical score editor The package appears to be lintian/pbuilder clean. The upload would fix these bugs: 444673 Changelog since the previous try (0.6.2-1): * New upstream version. * NtEd can run without the ALSA MIDI sequencer. In this case replay is disabled. * A new entry in the FAQ to deal with the startup error message Cannot open ALSA MIDI sequencer -- replay won't work ... * New upstream url. * Added debian/watch file. * debian/control - Use the Homepage: field to specify the upstream URL. - Updated long description to aknowledge that NtEd is also a player. * debian/rules - Some cleaning not handled by upstream distclean (.debs, datafiles/Makefile and po/Makefile). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/n/nted - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/n/nted/nted_0.7.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Gilles Filippini -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, 11 Oct 2007 08:16:17 -0400, Justin Pryzby [EMAIL PROTECTED] said: On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. [...] Possibly they meant CXXFLAGS, which is for the C++ compiler? [...] [0] My understanding is that the packaged kernels don't support 386 but with a software emulation of some math instruction patched in, 386 is advertised as being supported with binary packages. Support for 386 chips was officially dropped in Sarge [1]. I think it was because they weren't able to get the software emulation working without too much effort. But packages should still run on a 486 [2]. [1] http://www.debian.org/releases/stable/i386/ch02s01.html.en#id2530465 [2] But it is OK to include support for the extra instructions (MMX, SSE, etc.), as long it checks that they are supported before using them. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
Romain Beauxis [EMAIL PROTECTED] writes: rpath specifies where to find the required library. Debian wants *not* to use it since it messes with library update: one may want to move the library to a new place without breaking binaries depending on it. It also causes problems for multilib. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: polipo (updated package)
2007/10/11, Nelson A. de Oliveira [EMAIL PROTECTED]: On 10/11/07, DS [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 1.0.3-1 of my package polipo. Actually you didn't change the watch file, as you have described in your changelog :-) Oh! Sorry! Uploaded else one time. -- wbr Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: polipo (updated package)
Hello, On Thu, 11 Oct 2007, DS wrote: I am looking for a sponsor for the new version 1.0.3-1 of my package polipo. It builds these binary packages: polipo - a small, caching web proxy $ who-uploads polipo Uploads for polipo: 1.0.2-1 to unstable: Guus Sliepen [EMAIL PROTECTED] It is generally best if the previous sponsor (being the sponsor most familiar with your package) is asked first. Of course, sometimes new sponsors are required for a variety of reasons. Sponsees(?) should indicate in the RFS that they are looking for a new sponsor to replace an earlier one if that is the case. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: polipo (updated package)
2007/10/12, Kapil Hari Paranjape [EMAIL PROTECTED]: $ who-uploads polipo Uploads for polipo: 1.0.2-1 to unstable: Guus Sliepen [EMAIL PROTECTED] It is generally best if the previous sponsor (being the sponsor most familiar with your package) is asked first. Of course, sometimes new sponsors are required for a variety of reasons. Yes, I did it 5 days ago but Guus not answered yet. Should I wait or noise him by sending mails? If yes - I'll do it :) Sponsees(?) should indicate in the RFS that they are looking for a new sponsor to replace an earlier one if that is the case. -- wbr Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
Justin Pryzby-43 wrote: Is this the same package that caused dh_strip errors? No its not. Justin Pryzby-43 wrote: You shouldn't set rpath to /usr/lib since it's in the default search path. I haven't set the path any where in the rules file. but i am trying to install it using following line: $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr/ DESTDIR=$(CURDIR)/debian/tmp i added this line only after looking at the rules file of debian pkg already available on packages.debian.org. Earlier when i tried with $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp the make did installation on /usr/* not in debian/tmp/usr/*. Also after adding line (as given in debian pkg) the files were installed in debian/tmp/usr/* but two packages (-dev and -utils) that built contained no directory hierarchy. dpkg --contents on -dev and -utils showed only ./ so i modified rules file as shown. 80 dh_testdir 81 dh_testroot 82 dh_clean -k 83 dh_installdirs -a 84 mkdir --parents $(CURDIR)/debian/tmp/usr/include \ 85 $(CURDIR)/debian/tmp/usr/bin \ 86 $(CURDIR)/debian/tmp/usr/lib \ 87 $(CURDIR)/debian/tmp/usr/man/man1 88 89 $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr/ DESTDIR=$(CURDIR)/debian/tmp 90 dh_install -a 91 mkdir --parents $(CURDIR)/debian/libjpeg62-dev/usr/include \ 92 $(CURDIR)/debian/libjpeg62-dev/usr/lib \ 93 mkdir --parents $(CURDIR)/debian/libjpeg62-utils/usr/bin 94 95 install $(CURDIR)/debian/tmp/usr/include/* $(CURDIR)/debian/libjpeg62-dev/usr/include/ 96 ln -sf libjpeg.so.62.0.0 $(CURDIR)/debian/libjpeg62-dev/usr/lib/libjpeg.so 97 install $(CURDIR)/debian/tmp/usr/lib/lib*.a $(CURDIR)/debian/libjpeg62-dev/usr/lib/ 98 install $(CURDIR)/debian/tmp/usr/lib/lib*.la $(CURDIR)/debian/libjpeg62-dev/usr/lib/ 99 100 install $(CURDIR)/debian/tmp/usr/bin/* $(CURDIR)/debian/libjpeg62-utils/usr/bin/ 101 102 dh_link -a 103 dh_compress -a 104 dh_fixperms -a the output in verbose mode of dh_install -a is dh_install -a install -d debian/libjpeg62//usr/lib cp -a ./debian/tmp/usr/lib/libjpeg.so.62 debian/libjpeg62//usr/lib/ cp -a ./debian/tmp/usr/lib/libjpeg.so.62.0.0 debian/libjpeg62//usr/lib/ As you can see only one package is getting installed and rest of the two packages built were empty. Thats why i added lines below dh_install -a in the rules file. Justin Pryzby-43 wrote: can some one please explain the reason for this message? Debian considereds rpath to be inflexible. Justin Pryzby-43 wrote: You have to supply a ./debian/shlibs file in any package that includes public shared libraries (/usr/lib/*.so.*). It gets installed to /usr/lib/dpkg/info/ and searched by dh_shlibdeps when building packages to find on what package,version to add a dependency for a given objdump -p |grep -we NEEDED line. Justin Do i need to provide package-name.shlibs or shlibs.local file in debian directory. -- View this message in context: http://www.nabble.com/binary-or-shlib-defines-rpath-error-message-tf4607195.html#a13169417 Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
